Add log subscriptions to historian for thick clients

[garious]

Think clients and verifiers need access to the full log. Currently, the accountant receives new log entries by listening to a sync_channel held by the historian. Those entries are not serialized and do not cross the network.

Implementing this ticket might be accomplished by adding historian_stub and corresponding historian_skel that listens on the internal channel. It's also possibly we might want a generic "switchboard operator" that simply maps network protocols to our deserialized, well-typed channels.

[garious]

Since this ticket was opened, the historian's channel is now held by accountant_skel, and that object is turning into a catch-all microservice for any data a client/verifier needs. API calls like get_entries() are on-demand and return a response much bigger than the request, so a DOS attack is as easy as:

let first_id = stub.get_id(is_first=true);
loop {
    stub.get_entries(id=first_id);
}

We need to switch to a broadcast-oriented API where clients can subscribe for parts of the ledger, allowing the leader to control how much outbound traffic it is putting on the wire. Verifiers, on the other hand, may be less constrained and could offer a more flexible API.

[garious]

An incremental improvement would be to port the clients to tokio, so that our synchronous API can be implemented with futures instead of blocking calls. Futures are still clunky, however. What we really want is to leave our synchronous API as-is and use coroutines to interleave event handling. Unfortunately, it seems that's not too far along in Rust:

https://github.com/rust-lang/rfcs/blob/master/text/2033-experimental-coroutines.md

[garious]

Another option is to switch the API to something closer to a one-way street. Clients would listen for ledger updates. The server could cycle over the full ledger continuously so that new clients can clone it, and existing clients could recover after a restart. If we did that, client code can stick to its synchronous API and block all it wants on the client side.

[garious]

@aeyakovenko, did you want to try piping the thin client API through the thick client mechanism in this upcoming release? I'm okay pushing that back, but if you think it'd be easy, I can give it a go. I'm reworking the thin client right now anyway.

[garious]

Fixed in edf6272