#34565 refactor: extract BlockDownloadManager from PeerManagerImpl

• Separate block download logic from the net processing monolith so it can be tested and fuzzed in isolation

Extracts block download scheduling and tracking state from PeerManagerImpl and CNodeState into a new BlockDownloadManager module using the pimpl pattern. Rewires approximately 150 call sites across net_processing.cpp to the new class without altering existing cs_main synchronization semantics. Adds comprehensive unit tests and a dedicated fuzz harness exercising the new module boundary.

Problem: net_processing.cpp and PeerManagerImpl combine transaction relay, block download, headers sync, and compact block management into a single ~6200 line monolith, making block download logic difficult to test or fuzz in isolation without standing up the full node networking stack.

P3 · cleanup

• P3 because it is an architectural refactor that does not fix bugs or change wire protocol behavior
• Improves modularity and testability rather than removing concurrency bottlenecks

P3 because this is a clean architectural refactor that decomposes net_processing without fixing bugs or altering wire protocol behavior. As noted by Crypt-iQ and maflcko, the extraction preserves existing cs_main synchronization, so it improves modularity and testability rather than removing concurrency bottlenecks.

Membership: Refactors block download tracking and scheduling logic out of net_processing.cpp and CNodeState into a dedicated P2P manager.

Factors: security/stability 0, bug 0, performance 0, user value 0, leverage 1

• Needs rebase due to merge conflicts across net processing and build files

The PR has merge conflicts with the master branch across net_processing and build files that must be resolved before review.

Author status: Active, engaging with review feedback and demonstrating integration with conflicting proposals.

Open concerns:

• Crypt-iQ questioned whether decomposing PeerManagerImpl into separate classes adds unnecessary indirection compared to trimming CNodeState directly as in #35561.
• maflcko pointed out that block download remains coupled to cs_main, questioning whether the extraction genuinely simplifies lock reasoning.

Resolved concerns:

• w0xlt provided an exploratory branch demonstrating that the BlockDownloadManager extraction can cleanly coexist with the peer state refactoring in #35561.

• Concept approval without stated reasons (sedited, 0xbrito)
• Questions whether added indirection is worth it compared to #35561 (Crypt-iQ)
• Doubts benefit of moving code when cs_main requirements remain unchanged (maflcko)

Mild skepticism from Crypt-iQ regarding added indirection and tension with PR 35561; concept ACKs from sedited and 0xbrito.

Concept ACKs were received early, but maintainers and reviewers have raised nonblocking architectural questions about whether splitting out another manager adds indirection without removing lock coupling.

• sedited and 0xbrito gave Concept ACKs.
• Crypt-iQ expressed personal preference against indirection and noted tension with the approach taken in #35561.
• maflcko questioned the benefit of moving code when cs_main requirements remain unchanged.
• w0xlt replied with a proof of concept showing how both approaches could be combined.

Review verdicts (DrahtBot): 0

• Concept ACK: sedited, 0xbrito

Enables:

• Isolated fuzzing and testing of block download scheduling and stalling logic.

798 lines under test/bench/ci.

• src/net_processing.cpp +146/-584
• src/node/blockdownloadman_impl.cpp +644/-0
• src/test/blockdownload_tests.cpp +466/-0
• src/test/fuzz/blockdownloadman.cpp +330/-0
• src/node/blockdownloadman.h +226/-0
• src/node/blockdownloadman_impl.h +132/-0
• src/net_processing.h +0/-2
• src/CMakeLists.txt +1/-0
• src/test/CMakeLists.txt +1/-0
• src/test/fuzz/CMakeLists.txt +1/-0

This pull request extracts block download scheduling and tracking state from PeerManagerImpl and CNodeState into a new BlockDownloadManager module, rewiring approximately 150 call sites in net_processing.cpp and adding isolated unit and fuzz tests. It addresses the ongoing maintenance burden of net_processing.cpp by following the decomposition pattern previously used for TxDownloadManager in #30110. While sedited and 0xbrito provided Concept ACKs, reviewers Crypt-iQ and maflcko expressed mild architectural skepticism regarding added indirection while cs_main locking remains unchanged. The PR is currently dirty and requires a rebase against master before review can continue.