Re-evaluate rate-limiting for `BlobsByRange` requests

[michaelsproul]

Description

In the max_blobs_per_block PR we changed the heuristic for estimating the maximum number of blobs exchanged in a BlobsByRange request:

• Make max_blobs_per_block a config parameter #6329 (comment)

We are using a hardcoded constant (16) which is a bit higher than what we're likely to see in practice (6 before Electra, 9 after).

In a future PR we could try to plumb the ChainSpec into this function so we can get a more accurate estimate, or we could stick with the current approach if no issues arise because of it.

[michaelsproul]

Plumbing in the ChainSpec is a bit of a PITA. The RateLimiter really seems like it doesn't want to have a ChainSpec near it. The RPCHandler is fine because it has a ForkContext.

Maybe we could re-do @jxs's changes from this PR, but with ssz(skip_deserializing, skip_serializing) on the max_blobs_per_block field?

• Remove generic E from RequestId #6462

[michaelsproul]

This ended up getting fixed in the version of the max_blobs_per_block PR that we merged to unstable.