Switch GrandPa to new futures

[tomaka]

Transitions the code of substrate-finality-grandpa to Futures from the Rust standard library.

cc #3099

A few notes:

• All the changes are straight-forward. No logic has been touched. I know that the GrandPa code is sensible and have been extra-cautious.
• While stable futures, contrary to old futures, don't necessarily need to produce errors, for now I only removed error possibilities when it was obvious (e.g. internal channels that can no longer produce errors).
• I converted telemetry_connection_sinks in substrate-service to futures 0.3, but couldn't do the same for on_exit because there's this weird against-the-design-of-futures cloning capability. This will need to be done separately later after some brainstorming.
• I had to hard-code the H256 type for block hashes in communication/mod.rs, otherwise the compiler wouldn't be able to infer it. This is probably related to the fact that the items of the new Sink trait are now a regular generic parameter, rather than an associated type. The H256 block hash type is already hardcoded in GrandPa, so this is not a huge deal.
• This is unfortunately an API breaking change for nodes, because they have to add some compatibility shim when creating the Service.

Pre-requirement before merging: publish a new version of the finality-grandpa crate, and update the Cargo.toml of this PR.

[tomaka]

I naively forgot to fix the tests, but fixing the tests is quite complicated because the network (used in tests) still uses futures 0.1.

Still needs a bit of work.

[kigawas]

I naively forgot to fix the tests, but fixing the tests is quite complicated because the network (used in tests) still uses futures 0.1.

Still needs a bit of work.

I suggest migrating network to new futures first, but that part would also be kind of painful

[tomaka]

I suggest migrating network to new futures first, but that part would also be kind of painful

We can't actually migrate the network, as it's waiting for libp2p. We could, however, use the compatibility layer to make it look like the network has migrated.

However there's a chicken-and-egg problem. If we upgrade the network first, then the GrandPa tests will also fail to compile, as GrandPa would still use old futures.
We might have to upgrade GrandPa and the network together.

[kigawas]

However there's a chicken-and-egg problem. If we upgrade the network first, then the GrandPa tests will also fail to compile, as GrandPa would still use old futures.

How about upgrading the network to 0.3 futures and compat it as 0.1?

[tomaka]

This code is surprisingly tricky to upgrade: https://github.com/paritytech/substrate/blob/master/core/finality-grandpa/src/communication/mod.rs#L352-L361

One way to do this could be to use async_std::task::spawn in order to spawn the background futures. However the async_std library doesn't compile on stable right now, as it assumes async/await.

We might wait until 7th of November (stabilization of async/await) to finish this PR.

[Demi-Marie]

LGTM but I will wait on someone else to make the final call here.

[Demi-Marie]

Suggested change

	Box::pin(gossip.messages_for(GRANDPA_ENGINE_ID, topic).map(Result::Ok));
	Box::pin(gossip.messages_for(GRANDPA_ENGINE_ID, topic).map(Ok));

[Demi-Marie]

Futures 0.3 has been released

[Demi-Marie]

This needs a better justification. If there is no possible error, we should use a void type here. It is possible to implement a void type without an ICE.