ChainDB: let the BlockFetch client add blocks asynchronously

[mrBliss]

Fixes IntersectMBO/ouroboros-consensus#655.

Currently, the effective queue size when adding blocks to the ChainDB is 1 (for
why, see IntersectMBO/ouroboros-consensus#655). In this commit, we let the BlockFetch client add blocks fully
asynchronously to the ChainDB, which restores the effective queue size to the
configured value again, e.g., 10.

The BlockFetch client will no longer wait until the block has been written to
the VolatileDB (and thus also not until the block has been processed by chain
selection). The BlockFetch client can just hand over the block and continue
downloading with minimum delay. To make this possible, we change the behaviour
of getIsFetched and getMaxSlotNo to account for the blocks in the queue,
otherwise the BlockFetch client might try to redownload already-fetched blocks.

This is an alternative to #2489, which let the BlockFetch client write blocks to
the VolatileDB synchronously. The problem with that approach is that multiple
threads are writing to the VolatileDB, instead of a single background thread. We
have relied on the latter to simplify the VolatileDB w.r.t. consistency after
incomplete writes.

[mrBliss]

Draft because the impact on bulk sync speed should be measured.

[mrBliss]

Race condition: when a block has been removed but not yet written to the VolatileDB, this will return False. Possible solution: in the background thread, peek the block, process it, and then remove it from the queue. Add a comment that these two are not disjoint.

cc: @edsko.

[edsko]

Good thing someone is paying attention 🙄

[amesgen]

Routine cleanup of stale PRs targeting Consensus components (which nowadays live in https://github.com/IntersectMBO/ouroboros-consensus).

No work is lost, see https://stackoverflow.com/a/17954767.