`blob_sidecar_by_range` rate limiter is not based on config values

[eserilev]

The blob_sidecar_by_range rate limiter per the spec is MAX_REQUEST_BLOCKS_DENEB * MAX_BLOBS_PER_BLOCK. Our current rate limiting for this rpc request is set statically and isn't updated at BPO forks. We should make this value config driven so that we don't raise CRIT logs in SelfRateLimiter. We also need to make sure we don't incorrectly reject rpc requests when blob count increases.

[eserilev]

when backfilling I think were using current BPO numbers when making blob by range requests pre-fulu. I think that might be the actual issue here

[jimmygchen]

The default blobs by range limit is 896

lighthouse/beacon_node/lighthouse_network/src/rpc/config.rs

Lines 114 to 116 in 34dd1b2

	// `DEFAULT_BLOCKS_BY_RANGE_QUOTA` * (target + 1) to account for high usage
	pub const DEFAULT_BLOBS_BY_RANGE_QUOTA: Quota =
	Quota::n_every(NonZeroU64::new(896).unwrap(), 10);

Assuming each range request is 32 slots (Lighthouse behaviour), this will happen if the blob count is > 896 / 32 = 28
So i think this is not possible to happen on mainnet, because we won't be increasing the blob count to 28 within 18 days after Fusaka goes live. After 18 days, the blobs will no longer be available.

However, this will break complete-blobs-backfill once we get to max blobs per block = 28, and the node won't be able to backfill. (cc @michaelsproul )

[eserilev]

making the quota dynamic is pretty difficult. I think at the bare minimum we should have the quota value config driven so at least its updated when the config changes and the node is restarted