EIP4844: Remove sending empty blobs sidecar responses

[AgeManning]

This is a revival of #3174.

This PR clarifies the behaviour of the BlobsSidecarsByRange RPC response. Instead of sending empty BlobSidecar responses, we instead skip over the slot.

The main motivation for this is:

1. Clients can infer the empty blobs by lack of response. This prevents us from sending extra data, decoding redundant messages and identifying the empty object.
2. Prevents having to code extra logic to handle the exceptional case of the empty BlobSidecar.

I've spoken to all the client teams who seem to be in favour of this modification.

[dankrad]

Clients can infer the empty blobs by lack of response. This prevents us from sending extra data, decoding redundant messages and identifying the empty object.

It can sometime be useful to be able to encode information using more than just an absence of a response. In this case, it can be useful to know that an explicit claim is made that there are no blobs rather than it just missing (especially if the sidecar is signed, this is significant -- it would then be a claim by the block producers that no blobs are necessary to validate this block).

Prevents having to code extra logic to handle the exceptional case of the empty BlobSidecar.

I do not understand why there is extra logic. All the cryptography was designed to handle the empty blob sidecar without any extra logic, the math just naturally checks out if you set n=0.

[realbigsean]

There's a general point there that unavailable should be distinct from empty, but the block tells you what to expect via the list of kzg commitments and you need to verify the blob's claim vs the block anyways

especially if the sidecar is signed

they're not currently signed in ByRange

I do not understand why there is extra logic. All the cryptography was designed to handle the empty blob sidecar without any extra logic, the math just naturally checks out if you set n=0.

we don't want to write empty blobs sidecars to the database so we end up having special logic to avoid this and then reconstruct empty blobs sidecars based on the block to send to peers

[djrtwo]

From what I understand, all CL engineering teams support this change.

I initially made the case to have non-empty responses for blocks with no blobs. (1) symmetry between block and blobs calls, and (2) that in practice, eventually we won't have such 0-blob-blocks nearly as frequently as we see on testnets.

That said, I see that there might always be exceptional logic around handling this 0-blob-block (e.g. non DB write). And ultimately, the spec here doesn't affect overall safety or efficiency so I'm inclined to support the engineering opinion on how to do this.

Note, if this is merged, let's wait until #3244 is merged