Extend and expose PeerSelectionCounters

[bolt12]

Description

Closes #4815

[coot]

The withDelayCancellable & modifyPeersBasedOnCounter contain a bug: they update the targets and wait on the changes in the same stm transaction - changes in a single stm tx are not visible to the outside world until the transaction is committed, as a result we never update the targets.

I think it will be much better to write this code in a different way. We need a function which:

• update the targets to the specified value
• then block on the current counters until they reach the
  So I suggest that we implement:

updateTargets :: MonadSTM m
              => Tracer m (TracePeerSelection peeraddr)
              -> StrictTVar m PeerSelectionTargets
              -> StrictTVar m PeerSelectionCounters
              -> DiffTime
              -- ^ timeout
              -> (PeerSelectionTargets -> PeerSelectionTargets)
              -- ^ update counters function
              -> m ()

it should look something like (Haskell pseudocode):

updateTargets tracer peerSelectionVar countersVar timeout modifyTargets = do
 -- update targets
 targets <- atomically $ do modifyTVar peerSelectionVar modifyTargets
                            readTVar peerSelectionVar
 -- create timeout
 delayVar <- registerDelay timeout
 -- block until counters reached the targets, or the timeout fires
 atomically $ runFirstToFinish $
   FirstToFinish (readTVar countersVar >>= check . didCountersReachedTargets targets)
   <>
   FIrstToFinish (readTVar delayVar >>= check)               

Note that it runs in two STM transactions, so the outbound governor will have a chance to notice and act on modified targets.

[coot]

Suggested change

	-- For Peer Selection Governor this flag isn't much useful since one can do a
	-- lookup to LocalRootPeers set. But for miniprotocols this is useful
	-- information to carry around, namely for bootstrap peers optimisations.
	-- This data structure is passed to mini-protocol callbacks; the Genesis state
	-- machine relies on this information. See
	-- [issue#4815](https://github.com/IntersectMBO/ouroboros-network/issues/4815).

[coot]

Thanks @bolt12, I am closing it in favour of #4846 which was based on this PR.