Zebra: Tracking: State management service.

[hdevalence]

We should start a sketch of a state storage service, as in https://github.com/ZcashFoundation/zebra/blob/main/design/design.md#zebra-storage

Of the two points in that document, the first, storage of raw blocks, is much simpler than storage of other (processed, ingested) data. So we could start just by having a Service for raw block data, backed by RocksDB. This exercises setting up a database and providing an interface for it, but leaves all of the data modeling questions for later.

Edit: I think that a better approach is to start defining request/response pairs for queries from the rest of the node to the storage service, and implement those initially with an in-memory implementation with no persistence. This lets us refine what kinds of queries we want to make before committing to storage, and the initial implementation can later evolve into a test harness, allowing us to write tests about how functions behave with respect to particular chain state.

[hdevalence]

Blocked on #138

Edit: I think this is not the best approach, see above.

[dconnolly]

Use a HashMap or something similar as a skeleton for storing chain state, to start.

[hdevalence]

349 should be closed out before starting this.

[hdevalence]

I think a good first step towards all of the required scaffolding would be to be able to store and retrieve blocks by hash.

[dconnolly]

Closed by at least #473