Add individual by_range sync requests

[dapplion]

Issue Addressed

Part of

• Improve range sync with PeerDAS #6258

To address PeerDAS sync issues we need to make individual by_range requests within a batch retriable. We should adopt the same pattern for lookup sync where each request (block/blobs/columns) is tracked individually within a "meta" request that group them all and handles retry logic.

Proposed Changes

• Building on Generalize sync ActiveRequests #6398

second step is to add individual request accumulators for blocks_by_range, blobs_by_range, and data_columns_by_range. This will allow each request to progress independently and be retried separately.

Most of the logic is just piping, excuse the large diff. This PR does not change the logic of how requests are handled or retried. This will be done in a future PR changing the logic of RangeBlockComponentsRequest.

Before

• Sync manager receives block with SyncRequestId::RangeBlockAndBlobs
• Insert block into SyncNetworkContext::range_block_components_requests
• (If received stream terminators of all requests)
  • Return Vec<RpcBlock>, and insert into range_sync

Now

• Sync manager receives block with SyncRequestId::RangeBlockAndBlobs
• Insert block into SyncNetworkContext:: blocks_by_range_requests
• (If received stream terminator of this request)
  • Return Vec<SignedBlock>, and insert into SyncNetworkContext::components_by_range_requests
  • (If received a result for all requests)
    • Return Vec<RpcBlock>, and insert into range_sync

[realbigsean]

Looks really good overall!

[realbigsean]

The _blocks_req_id here is unused and blobs_req_id is only used to check if a blobs request was made. I don't see these send_ methods used anywhere else so I think we can return Result<(), ..> rather than Result<BlocksByRangeRequestId, ..> for blocks. Maybe a bool for blobs. Looks like for custody columns, we care about the count requested but not particular ids

[dapplion]

In a future PR RangeBlockComponentsRequest will track individual requests by ID. Left this variable named but unused as a hint that it should be used.

[dapplion]

Rebased on latest unstable, @jimmygchen ready for another review

[jimmygchen]

Should we rename this to block_component or range_block_component?

[dapplion]

Yeah! 000bc5512

[jimmygchen]

Looks great!

The id naming was a bit confusing to me at first, but overall the logic is actually simpler than I thought 👍

[realbigsean]

Nice, couldn't find any issues

[jimmygchen]

Looks great! Thanks