#35113 net: introduce block tracker to retry to download blocks after failure

• Automatically retry on-demand block downloads across available peers when a peer fails or disconnects
• Relieves callers from manually tracking and retrying missing block fetch requests

This PR introduces a BlockRequestTracker class to track manual on-demand block downloads initiated via the getblockfrompeer RPC. If an assigned peer disconnects or fails to respond, the node automatically retries fetching the block from another available peer. It also updates getblockfrompeer to make the peer_id parameter optional and adds a retry flag.

Problem: The getblockfrompeer RPC is asynchronous and cannot inform callers if the requested peer disconnected or failed to deliver the block. Callers must manually monitor and retry the request, and cannot simply ask the node to fetch a missing block from whatever peer is available.

P3 · new feature

• P3 because it removes friction when fetching missing blocks and lays groundwork for pruned rescans
• Deferrable since it does not affect standard initial block download or regular block relay

Automating retries for on-demand block downloads removes friction for node operators fetching pruned or missing blocks. It is framed as building infrastructure for prune node rescans (#29183), but is deferrable since it does not affect standard initial block download or normal block relay.

Membership: Adds BlockRequestTracker and integrates manual block download retries into PeerManagerImpl and FindNextBlocksToDownload.

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

P3 · user request

• P3 because it lets callers fetch blocks without looking up specific peer IDs first
• Benefit is an incremental convenience enhancement to a diagnostic RPC command

Directly addresses user issue #27652 by allowing getblockfrompeer to query any available peer rather than requiring manual peer lookup. While useful for node operators and external utilities, it is an incremental improvement to an existing diagnostic RPC.

Membership: Modifies the getblockfrompeer RPC interface to make peer_id optional and add a retry parameter.

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

• Has merge conflicts against master and needs a rebase
• Author has been inactive after agreeing to address RPC design feedback

The PR has merge conflicts against current master and the author has been inactive for 140 days.

Author status: silent since 2026-04-30 after stating they would consider the RPC parameter comments in upcoming changes

Open concerns:

• luke-jr requested changes regarding the RPC parameter interface, noting that boolean flags should not be positional arguments and suggesting an options object instead
• Parameter validation and documentation around the default retry behavior and omitting peer_id need refinement

• Unaddressed objection: boolean parameters should be named rather than positional (luke-jr)
• Author agreed to consider RPC parameter feedback but has not pushed updates

Disputed: luke-jr requested changes on positional boolean parameters and argument validation; author acknowledged but has not updated

luke-jr submitted a Changes Requested review objecting to positional boolean parameters on the RPC and clarifying default behaviors. The author agreed to consider the points, but has not pushed updates.

• luke-jr commented that booleans should ideally be named rather than positional parameters and requested changes
• optout21 acknowledged the feedback, stating 'I will consider them with upcoming changes'

Review verdicts (DrahtBot): 0

Enables:

• #29183

99 lines under test/bench/ci.

• test/functional/rpc_getblockfrompeer.py +99/-0
• src/block_request_tracker.cpp +90/-0
• src/block_request_tracker.h +71/-0
• src/net_processing.cpp +58/-5
• src/rpc/blockchain.cpp +8/-3
• src/net_processing.h +2/-2
• src/CMakeLists.txt +1/-0
• src/rpc/client.cpp +1/-0

• Whether the author plans to resume work or if the PR will stall like its predecessor #27837

This PR introduces a BlockRequestTracker to manage on-demand block downloads initiated via getblockfrompeer, automatically retrying downloads across alternative peers if the assigned peer disconnects or fails. It also updates the RPC so users can fetch a block from any available peer without providing a specific peer ID, resolving an open request (#27652) and supporting the prune node rescan effort (#29183). The PR is currently in draft with merge conflicts and open change requests from luke-jr regarding RPC argument structure, with no author updates in over four months.