Add DataColumnSidecarsByRange v1 Req/Resp

[hwwhww]

Add DataColumnSidecarsByRange message for syncing as @jimmygchen suggested in #3574 (comment).

The description was copied and edited from Deneb BlobSidecarsByRange.

@djrtwo mentioned (#3574 (comment)) that considering the load-balancing, it's unclear if plural columns: List[ColumnIndex] or single column: ColumnIndex makes more sense. I now use columns: List[ColumnIndex] for flexibities.

[jimmygchen]

Load-balancing is an interesting idea, although it's unclear to me if we need it with the current setup.

When node is performing custody columns sync, they'll be downloading from peers in the same column subnet, so the ByRange requests they send could contain all the columns assigned to that subnet, so I think plural columns make sense. Given the response size wouldn't be much bigger than BlobsByRange today (potentially way smaller depending on custody_requirement), feels like it would be much simpler to download custody columns from the same peer so we don't have to worry about some peers being faster / slower.

When performing historic sampling, we'd likely be requesting the bulk of the samples from a different set of peers (different columns), so it probably wouldn't put too much additional load to the same peer that we're gathering custody from?

Perhaps load-balancing could be use as an optimisation technique to speed up syncing? and in either case, plurals would probably be more flexible.

[dapplion]

👍 on the addition

Want to note that this protocol is helpful to speed up forward sync and backfill sync for a custody peer to quickly fetch its columns. However, it's at odds with the server peer rate-limiting outgoing bandwidth shared between syncing and sampling peers. If by range requests will be rate-limited to the point that they become the bottleneck for syncing then there's not much benefit to just waiting to fetch the block first and then requesting by root.

[ralexstokes]

don't have the full context to say more at the moment, but the suggestion make sense

would have to go review the full peerDAS spec as-is now to say more on if this is the best way to handle this...

[ppopth]

I think this makes sense and should be implemented.

[hwwhww]

I'm going to merge it for the interop milestone requirements. Thank y'all for reviewing it!