storage rework / simplification for next phase

[vincenthz]

• get rid of chain-core (some of the) properties in storage (optional)
• remove sqlite indices and replacing by in-memory indices in btree-map (BlockHash -> ..) and Sequential / Geographical data structure (data height, date)
• remove the storage trait, in favor of a simple implementation with possibly only 3 backends (dynamic branching would do) that we care about for storing blocks : memory, sqlite, hdb (branch in chain-libs). it's possible that some backends could cache, e.g memory cache of blocks then other backend also.

[mzabaluev]

Not sure if this should be done as part of this rework, but some solution to connection pooling and backend-optimal support for concurrent queries may be required to properly implement async queries in jormungandr. This is, however, not a call to async-ify the storage stack throughout, because there are no mature database engines supporting async queries at the moment and the vibe I get from researching similar issues elsewhere (e.g. diesel-rs/diesel#399) is that it may not be worth it, compared to a simpler solution of shipping off database queries to synchronous jobs in a thread pool.

[vincenthz]

in term of async, I was just thinking providing async apis for clients of the storage, but the main storage would be done threadpool style (with 1 thread to start with)

[mzabaluev]

A sanity-preserving boundary may be for chain-storage to abstract the storage backend as a single-threaded "connection" with Send and the usual mutability semantics and synchronous operation methods, and let the application take care of pooling and threading the instances. Construction of connection instances would likely be backend-specific in any case, so a problem of sharing state or synchronization between connections, if necessary, can be solved there with no need for a common abstraction.

[eugene-babichenko]

Do we have any actual storage benchmarks?

[vincenthz]

At the moment, there's no benchmarks, but going forward it would be good to have some in two different categories:

1. storing/retrieving blocks
2. index related operations

[eugene-babichenko]

Is the storage intended to be used by any 3rd party libraries, or is it just for use in Jormungandr?

[eugene-babichenko]

This is mostly done. The only thing that is still on the to-do list is to remove the dependency on chain-core properties.