Dagstore lotus mount Implementation with tests

[aarshkshah1992]

TODO

• Unit Tests for the Loutus Mount API impl.
• Replace mocked out DAG store with actual DAG store Integrate dag store into mount implementation #565
• Register shard after handoff deal completes (when deal has been successfully sent for sealing)
• Destroy shard when storage deal expires / is slashed
  • LotusMount.Stat.Exists should be false when storage deal expires.
• Shard failure and recovery

[dirkmc]

Couple of nits but LGTM 👍

The mount implementation isn't really specific to lotus, should we call it something other than LotusMount?

[aarshkshah1992]

@dirkmc Notes on integrating the Sharded DAG Store into Lotus and Markets:

1. Instantiate the Sharded DAG Store with the correct Config in Lotus. It's likely some of that Config will flow from the Lotus Config. The instantiation will take care of "rehydrating" the DAG Store so we don't need to worry about that. We'll instantiate and inject the Lotus Mount/Mount factory/Type here so they make their way into the Mount Registry of the DAG Store.

2. Register Shards in the storage market after deals have been successfully sent for sealing (i.e. storage deal enters the StorageDealAwaitingPrecommit state on the Miner). If this fails, keep retrying till this succeeds with the "Sharded DAG Store failure management and Recovery" mechanism. Note that we can pass in the CARv2 file that Graphsync wrote out for us as part of the "RegisterShard" call here in the RegisterOpts option there to ask the Sharded DAG Store to simply scrap off the Index from the CARv2 file we already have rather than fetching the CARv1 payload from the Unsealer and indexing it all over again.

3. In the retrieval Market, we'd call "AcquireShard" to get a ShardAccessor /ReadOnlyBlockstore that we can serve the retrieval from. It's important that we call Close on this accessor when we no longer need it (successful or failed retrieval) so the DAG Store can clean up transient artefacts it creates for this retrieval. If the call "AcquireShard" fails, we'd have to use the same failure management/recovery mechanism mentioned above.

4. Also note that we might eventually decide that we need lazy registration of Shards (after having this discussion with @raulk in today's huddle) for all pre-existing deals to avoid the tricky migration effort there and in that case, the lazy shard registration i.e. calling ""RegisterShard" would also happen in the retrieval market.

[aarshkshah1992]

@dirkmc Shifting review and TODOs to the feat/dagstore-retrieval here so I can review all the changes together.