* Change `client::{future, sync}, server::{future, sync}` to `future::{client, server}, sync::{client, server}`
This reflects the most common usage pattern and allows for some types to not need to be fully qualified when used together (e.g. the previously-named `client::future::Options` and `server::future::Options` can now be `client::Options` and `server::Options`).
* sync::client: create a RequestHandler struct to encapsulate logic of processing client requests.
The largest benefit is that unit testing becomes easier, e.g. testing that the request processing stops when all request senders are dropped.
* Rename Serialize error variants to make sense.
* Rename tarpc_service_ConnectFuture__ => Connect (because it's public)
* Use tokio proto's ClientProxy.
Rather than reimplement the same logic. Curiously, this commit
isn't a net loss in LOC. Oh well.
* Factor out os-specific functionality in listener() into their own fns
* Remove service-fn dep
The basic strategy is to start a reactor on a dedicated thread running a request stream.
Requests are spawned onto the reactor, allowing multiple requests to be
processed concurrently. For example, if you clone the client to make requests
from multiple threads, they won't have to wait for each others'
requests to complete before theirs start being sent out.
Also, client rpcs only take &self now, which was also required for
clients to be usable in a service.
Also added a test to prevent regressions.
