Part of #27463.
This PR does 3 things:
(1) It modularizes transaction download logic into a TxDownloadManager. Transaction download logic refers to the process of deciding what transactions to request, download, and validate.[1] There should be no behavior changes. Using --color_moved=dimmed_zebra -w may help.
(2) It adds unit and fuzz (:magic_wand:) testing for transaction download.
(3) It makes a few small behavioral changes:
- Stop (debug-only) logging tx invs during IBD
- Just like all other transactions, require orphans have RecursiveDynamicUsage < 100k before adding to vExtraTxnForCompact
- Don’t return a 1p1c that contains a parent or child in recent rejects. Don’t process any orphan already in recent rejects. These cases should not happen in actual node operation; it’s just to allow tighter sanity checks during fuzzing.
There are several benefits to this interface, such as:
- Unit test coverage and fuzzing for logic that currently isn’t feasible to test as thoroughly (without lots of overhead) and/or currently only lightly tested through assert_debug_log(not good) in functional tests.
- When we add more functionality (e.g. package relay messages, more robust orphan handling), the vast majority of it will be within TxDownloadManagerinstead ofPeerManager, making it easier to review and test. See #28031 for what this looks like.
- PeerManagerwill no longer know anything about / have access to- TxOrphanage,- TxRequestTrackeror the rejection caches. Its primary interface with- TxDownloadManagerwould be much simpler:- Passing on  ValidationInterfacecallbacks
- Telling txdownloadmanwhen a peer {connects, disconnects}
- Telling txdownloadmanwhen a {transaction, package} is {accepted, rejected} from mempool
- Telling txdownloadmanwhen invs, notfounds, and txs are received.
- Getting instructions on what to download.
- Getting instructions on what {transactions, packages, orphans} to validate.
- Get whether a peer HaveMoreWorkfor theProessMessagesloop
 
- Passing on  
- (todo) Thread-safety can be handled internally.
[1]: This module is concerned with tx download, not upload. It excludes transaction announcements/gossip which happens after we download/accept a transaction. Txreconciliation (erlay) is excluded from this module, as it only relates to deciding which invs to send or helping the other peer decide which invs to send. It is independent from this logic.