segregate chain and state blockstores

[raulk]

Builds on #5484.

---

This paves the way for better object lifetime management.

Concretely, it makes it possible to:

• have different stores backing chain and state data.
• having the same datastore library, but using different parameters.
• attach different caching layers/policies to each class of data, e.g. sizing caches differently.
• specifying different retention policies for chain and state data.

This separation is important because:

• access patterns/frequency of chain and state data are different.
• state is derivable from chain, so one could never expunge the chain store, and only retain state objects reachable from the last finality in the state store.

---

I originally submitted this in #4771, but we @vyzo and I decided to do away with the caching for now. That was in the context of LMDB experiments (which uses the page cache aggressively). It may make sense to reintroduce Freecache on top of the hot badger store.

[Kubuxu]

SGWM

[travisperson]

Is there a migration path for existing datastores to splitstore?

[vyzo]

It should happen automagically; on first run with the splistore, it will warm the hotstore by fetching all reachable objects from the old blockstore, which becomes the coldstore.

The directory structure looks like this:

.lotus
  datastore
    chain -- the old blockstore, now coldstore.
    splitstore
      hot.badger -- the hot blockstore, badger.
      tracker.bolt -- the tracking db, which is a BoltDB file.

[raulk]

@magik6k ready again.