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

PeerManagerImpl::ProcessMessage() is a ~1000-line function handling every p2p message type inline, which makes it hard to navigate and review.

This PR continues splitting it into per-message helper functions, following the pattern of the recently merged fa5ab0220e02377c3c855042ecdf1f5f950d0965 (ProcessPong()) and fa55723b8fbd4fd056dddac5b35daf2e86021422 (ProcessAddrs()),, as suggested by @maflcko #34588 (comment).

Seven handlers are extracted, one commit each:

• ProcessGetAddr() — getaddr
• ProcessGetDataMessage() — getdata (named to avoid colliding with the existing ProcessGetData(), which services the request queue this handler fills)
• ProcessGetBlocks() — getblocks
• ProcessGetHeaders() — getheaders
• ProcessInv() — inv
• ProcessSendTxRcncl() — sendtxrcncl
• ProcessTx() — tx

Each commit is a pure code move: the only new lines are the declaration (with thread-safety annotations), the function signature, and the one-line call site. Each call site is Helper(...); return;, so return statements inside the moved bodies keep identical semantics. No behavior change.

Every commit can be reviewed with the git options: --color-moved=dimmed-zebra --color-moved-ws=ignore-all-space

Declarations and definitions are placed next to related existing helpers (e.g. ProcessGetDataMessage next to ProcessGetData, ProcessGetBlocks next to ProcessGetBlockData, ProcessGetAddr after ProcessAddrs).

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35502.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

Concept ACK. Pretty straightforward change that makes it easier to navigate net_processing and better encapsulates logic.

Concept ACK

Fwiw this has been proposed at least once: #9608 (it seems to have failed more due to lack of review back then rather than on strong pushback, as far as I understand)

Concept ACK.

I'm in favour of these refactoring, while reviewing #34824 also identified another possible candidate SendMessages() which is in the same file.