Use hyper 0.11 in ethcore-miner and improvements in parity-reactor

[sorpaas]

This aligns ethcore-miner's hyper dependency with the rest of the crates. However, we still have secret-store depending on hyper 0.10 and I'm planning to fix that in a separate PR.

• parity-reactor's Remote::spawn_fn now exposes the raw Remote's handle. This allows the EventLoop to be used in many tokio contexts.
• parity-miner is updated to use async hyper request. This, probably until we get tokio runtime, would need to pass the Remote handle around.

[debris]

looks good to me. @0x7CFE can you also look into it?

[0x7CFE]

LGTM

[tomusdrw]

Wouldn't it be better to use fetch instead of raw hyper?

[sorpaas]

I'm not sure whether we can use fetch to send POST request. The fetch crates looks like to use a background thread and is hard coded to only send GET request? https://github.com/paritytech/parity/blob/master/util/fetch/src/client.rs#L216

[debris]

this is changed in #6422 which will be merged in a second https://github.com/paritytech/parity/pull/6422/files#diff-3eef53ff37b934cea2e67f6f251a2377R131

[sorpaas]

Got it. I'll try to get a version based on fetch once that PR is merged.

[tomusdrw]

I'm not sure if parity_reactor abstraction is something we want/should keep.

[sorpaas]

I totally agree that some day we should remove the reactor wrapper and just use the new plain Tokio Runtime (which also gets a better ThreadPool executer, and allows us not to pass Handle/Remote everywhere!). However, it looks like currently libraries haven't matured enough to do that. For example, hyper still doesn't support solely using Tokio Runtime as of now. So I think currently we still need to keep using reactor abstraction and fix stuff based on that, before we can remove it?

[sorpaas]

Okay I have done a new version using fetch. There're several things to note.

Improvements/fixes done on fetch crate:

• The redirection following logic is fixed to align with HTTP standard. Our current implementation will follow everything using the original METHOD and URL. However, this should only be done for 307 and 308 (Temporary Redirect and Permanent Redirect). For 301, 302, and 303, the request should instead always be GET.
• fetch is extended to allow fetching arbitrary requests. This fixes the current problem that we cannot POST message body. With this change, I added a new struct Request. This is a wrapper around hyper::Request with a) Changed from using Uri to use Url, as this seems to be what's being used in the rest of the crate, b) Support Clone operation, this is need for redirection following logic, and c) with_ helper functions to allow easier building.
• A type problem raises because now we're not parsing Url in Fetch::fetch, but in Fetch::get and Fetch::post. The issue is that Rust compiler cannot figure out the return type if those functions are predefined trait functions. So I have to move them to trait implementations. We only have one Client implementation for Fetch with all others being test structs. So this is probably not a problem, but if you have a fix for this please let me know.

Regarding miner crate:

• @tomusdrw I still need to keep parity-reactor dependency in miner. The issue is that Fetch returns a Future and I would need to spawn it somewhere.
• Remote and FetchClient parameter passing is moved to CLI, so we don't need to change too many function calls. Miner::push_notifier automatically handles seal_work.enable.