BlockFetchConsensusInterface.readFetchedBlocks: report blocks as fetched as soon as they are enqueued

[amesgen]

Currently, the readFetchedBlocks from BlockFetchConsensusInterface we provide to Network is implemented via ChainDB.getIsFetched (which in turn is implemented via VolatileDB.getIsMember). When a new block is added from a BlockFetch client, it might therefore take a bit of time until the block has been written to disk, and is hence reported as fetched by readFetchedBlocks.¹

This might occasionally lead the BlockFetch decision logic to unnecessarily request the block from another peer, even though it has already been downloaded, just not yet written to disk.

I implemented an ad-hoc fix for this (also reporting blocks in the queue as fetched) here: main...amesgen/getIsFetched-bg-queue
@karknu tested this change, and observed that it fixes the behavior described above.

It would be nice to validate and clean-up this patch.

Footnotes

1. This is the (weaker) requirement that is currently stated on mkAddFetchedBlock:

   Upon successful completion of addFetchedBlock it must be the case that readFetchedBlocks reports the block.

   ↩

[amesgen]

This should be fixed by #1179 as a side-effect of containing a ported version of IntersectMBO/ouroboros-network#2721 (but didn't test that yet)