Add log subscriptions to historian for thick clients

[hypercube-lab]

Consider if clients and verifiers need access to the whole log. At the moment, the accountant gets fresh log entries by listening to a sync channel that is controlled by the historian. There is no serialization of such entries, and they do not travel throughout the network.

This ticket's implementation may be done by adding historian stub and a matching historian skel that listens on the internal channel to the database. Another possibility is that we will need a generic "switchboard operator" that simply translates network protocols to our deserialized, well-typed channels.

[alexandria999eth]

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

[alexandria999eth]

To achieve the same performance with futures instead of blocking calls, we can port our clients to Tokio so that our synchronous API can be used with futures. However, futures are still awkward. What we really want is to use coroutines to interleave event handling within our synchronous API. Regrettably, that's really early in Rust 

[alexandria999eth]

Alternatively, the API may be changed to make it more like a one-way street. To hear updates, clients will only be asked to be available. A continuous cycle for the ledger might be possible, and that would allow new clients to be cloned, while existing clients will be able to recover from a restart. We could have the client-side code block entirely, so that the synchronous API that we use for the clients works as it should.

[hypercube-lab]

@all-contributors please add @alexandria999eth for infrastructure, tests and code

[allcontributors]

@hypercube-lab

I've put up a pull request to add @alexandria999eth! 🎉