Another JSON-RPC refactor

[tomaka]

This would be the third refactor of the JSON-RPC service, but I'm slowly learning how to do it properly.

This is how it would look like:

• In lib.rs, add a "reverse proxy" that binds the socket (or equivalent) and the actual requests processor(s). The role of this reverse proxy is to maintain coherency from the socket point of view in case a requests processor crashes. It also has the responsibility of enforcing the number of subscriptions, to ensure equal balancing of requests when there is more than one JSON-RPC client, and to send unsubscribe requests if a client disconnects.

• In light-base and full node, add a "requests processor": a single-threaded task (no sub-tasks) that processes requests either immediately or by pushing them to a FuturesUnordered. From the point of view of this requests processor, there is only a single JSON-RPC client. This requests processor would be relatively simple, as it doesn't need to handle everything handled by the reverse proxy.

• In light-base and full node, connect the two with channels. The full node would have multiple requests processors.

[tomaka]

cc #519 and to some extend #1382

[tomaka]

Adding a single JSON-RPC reverse proxy (as in #1436) seems really over-complicated.

However, we can split it in two:

• A "client sanitizer" that merges/discards notifications in case a JSON-RPC client is too slow, and also generates unsubscribe JSON-RPC requests when the client disconnects.
• A "server dispatcher" that redirects requests to servers, and properly handles when a server is removed.