`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.[^1]

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: https://github.com/IntersectMBO/ouroboros-consensus/compare/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.

[^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 https://github.com/IntersectMBO/ouroboros-network/pull/2721 (but didn't test that yet)

[amesgen]

Should be fixed by 318e9a5a057af29f09180138e7b7b7f8a678d82f