Fix leak in range sync components_by_range_requests

[jimmygchen]

Issue Addressed

When a data column range sync fails with coupling error returned below, if the coupling error does not contain a column and peer (i.e. column_and_peer == None)

lighthouse/beacon_node/network/src/sync/block_sidecar_coupling.rs

Lines 286 to 292 in 9181ff4

	fn responses_with_custody_columns(
	blocks: Vec<Arc<SignedBeaconBlock<E>>>,
	data_columns: DataColumnSidecarList<E>,
	column_to_peer: HashMap<u64, PeerId>,
	expects_custody_columns: &[ColumnIndex],
	spec: &ChainSpec,
	) -> Result<Vec<RpcBlock<E>>, CouplingError> {

The entire batch gets retried, without the previous context.components_by_range_requests entry being removed, this result in unbounded memory usage increase as shown in the metric:

Note: this PR is not tested and I'm not sure if the fix is good - but just wanted to illustrate the issue.

[jimmygchen]

Note that this hack didn't fix it

The metric i was looking at is sync_active_network_requests, type == components_by_range, recorded here:

lighthouse/beacon_node/network/src/sync/network_context.rs

Lines 1705 to 1708 in 790c94c

	(
	"components_by_range",
	self.components_by_range_requests.len(),
	),

This change what caused entries not to be removed i believe, its used by both range and backfill:

lighthouse/beacon_node/network/src/sync/network_context.rs

Lines 745 to 751 in 790c94c

	if blocks_result.is_ok() {
	// remove the entry only if it coupled successfully with
	// no errors
	entry.remove();
	}
	// If the request is finished, dequeue everything
	Some(blocks_result.map_err(RpcResponseError::BlockComponentCouplingError))

[jimmygchen]

This will be fixed properly by @pawanjay176 in #7762.