Add new gossip rule to REJECT sidecars with index >= MAX_BLOBS_PER_BLOCK

[tbenr]

Introduce a new rule to avoid propagation of sidecars that have an index >= MAX_BLOBS_PER_BLOCK.
Current rules allow proposer to publish an unbounded number of sidecars that will be accepted by clients.

[g11tech]

actualy the previous check itself assures that this is not unbounded : compute_subnet_for_blob_sidecar(sidecar.index) == subnet_id so this is a redundant check

[StefanBratanov]

Not true though because compute_subnet_for_blob_sidecar calculates the subnet_id using mod BLOB_SIDECAR_SUBNET_COUNT, so for example for subnet 4 and index 100, compute_subnet_for_blob_sidecar(100) == 4 thus valid according to the rule.

[g11tech]

ahh in that case do we want it to be hardfork independent MAX_BLOB_COMMITMENTS_PER_BLOCK or MAX_BLOBS_PER_BLOCK? (although the tighter bound of max blobs per block makes sense)

[djrtwo]

I believe @tbenr and @StefanBratanov are correct and that this should be bounded

There is an equivalent condition for beacon_attestation subnets here -- https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#beacon_attestation_subnet_id

REJECT] The committee index is within the expected range -- i.e. data.index < get_committee_count_per_slot(state, data.target.epoch)

I would argue that this should be the first condition -- before the second condition that calls compute_subnet_for_blob_side_car. Tossing out junk first (and mirroring the order in the attestation subnet)

[tbenr]

I would argue that this should be the first condition ...

True, we could save the function call but currently computes just a modulo.
Teku will perform this in this order in any case because we do the subnet_id check closer to the networking layer and the actual gossip validation runs on top of it.

[g11tech]

redundant check already enforced by subnet id check

[djrtwo]

I"m going to get this into the release today

[djrtwo]

Thanks @tbenr for finding this!