#35502 refactor: extract per-message helpers from ProcessMessage (move-only)

• Break up an oversized message processing routine to make the code easier to navigate.
• Allow compile-time thread-safety checks to enforce only the specific locks needed for each message type.

Splits the monolithic PeerManagerImpl::ProcessMessage() method in net_processing.cpp into discrete per-message helper functions such as ProcessGetAddr, ProcessGetDataMessage, ProcessInv, ProcessTx, ProcessCompactBlock, and ProcessVersion. Each extraction is kept in its own commit as a pure move-only refactor without behavioral changes.

Problem: ProcessMessage() was an oversized routine of more than 1,000 lines handling all message types inline. This made code navigation cumbersome and forced the entire method to declare a broad set of mutex requirements rather than checking only the specific locks needed by each message type.

P3 · cleanup

• P3 because it improves internal maintainability and narrows compile-time lock requirements.
• It carries no user-facing changes, protocol updates, or bug fixes.

Worthwhile internal code cleanup that breaks down a massive message processing function and allows narrower compile-time thread-safety annotations. As noted by w0xlt, 'it makes the per-message lock contract more local and compiler-checked.' However, it carries no user-facing changes, protocol updates, or bug fixes, making it reasonably deferrable.

Membership: Directly refactors PeerManagerImpl::ProcessMessage() in src/net_processing.cpp.

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

• Ready for review, cleanly structured as pure move-only commits with passing CI.

The PR is freshly rebased, CI is clean, and commits are structured as pure moves verifiable with git move-detection options.

Author status: active; recently rebased to resolve review comments and incorporated suggested extractions

Resolved concerns:

• davidgumberg questioned whether separate helpers obscure caller assumptions and control flow compared to a flat switch, but conceded that other contributors prefer this style.
• pablomartin4btc suggested also extracting CMPCTBLOCK and VERSION, which the author incorporated in subsequent commits.

• Strong consensus among P2P contributors that helpers improve navigation and lock checks
• Support for easier navigation and better git diff context (stickies-v, theStack, pablomartin4btc, maflcko)
• Verified move-only correctness and thread-safety annotations (pseudoramdom, thomasbuilds)
• Questioned whether helpers obscure control flow compared to a flat switch (davidgumberg)

Strong consensus among P2P contributors on code cleanliness and tighter lock annotations, with one resolved style concern.

Multiple contributors gave Concept ACKs and code-review ACKs noting benefits for diff context and lock verification, while the only skeptic conceded that community preference should prevail.

• stickies-v Concept ACKed for easier navigation and better logic encapsulation.
• theStack Concept ACKed noting historical attempts.
• pablomartin4btc ACKed and co-authored additional extractions.
• maflcko Concept +1'd for improved git diff context and consistency with existing helpers.
• davidgumberg expressed Concept -0 regarding navigation friction but conceded the stylistic choice to others.
• pseudoramdom and thomasbuilds verified move-only correctness and clang thread-safety annotations.

Review verdicts (DrahtBot): 0 (+3)

• Stale ACK: pseudoramdom, thomasbuilds, pablomartin4btc
• Concept ACK: stickies-v, theStack

0 lines under test/bench/ci.

• src/net_processing.cpp +1012/-940

This PR breaks up the monolithic PeerManagerImpl::ProcessMessage() routine in src/net_processing.cpp by extracting handlers for nine individual P2P message types into separate move-only helper functions. It improves maintainability, simplifies diff inspection, and allows clang thread-safety annotations to be scoped locally to each message type. The changes are move-only and have received solid review and agreement across multiple contributors, with a minor stylistic discussion resolved. It carries no protocol or behavioral changes, representing a worthwhile cleanup without immediate urgency.