Production RPC client

[tcharding]

There is a draft up already: #505 by @jamillambert and @satsfy is keen to work too.

• We have the green light to add feature gated async support to jsonrcp (using bitreq)
• WIP: Create an async corepc-client (adding async support to jsonrpc) #505 shows which methods should IMO be included in v0.1.0.
• IMO the prod client should be async only and unconditionally use jsonrpc and bitreq (with async enabled) but leaving that up to the implementors

Let's ship already.

[luisschwab]

You guys could get fancy and make it sans-IO, allowing the user to bring their own transport.

[tcharding]

We had this discussion already somewhere and the result was IIRC, there is no real usecase so no justification for the added complexity.

[satsfy]

At the jsonrpc layer, the client already can use any transport shape via Transport and Client::with_transport. So the JSON-RPC client itself does not need to know whether requests go over bitreq, or something else. The tokio coupling is in the default async HTTP transport bitreq (and future bitreq/async). Issue #520 explores the idea of making bitreq runtime-agnostic. So IMO sans-IO is possible but not a priority for production client atm. bitreq would be corepc default transport but downstream users should able to configure their own jsonrpc::client_async::Transport. Later, a solution to #520, or a separate non-bitreq transport, may enable runtime-agnostic/sans-IO.

[luisschwab]

Yep, just exposing that should be enough.