Simplify blobSidecar availability checker

[tbenr]

Assuming the following is true:
validating kzg commitments and inclusion proof guarantees that blobs and commitments are valid and that the commitments are part of the block.

Thus, if we always do those checks before sending the blobSidecar in the pool (BlockBlobSidecarsTrackersPoolImpl), then we can remove all the complex, two-step, checks we do on in ForkChoiceBlobSidecarsAvailabilityChecker and the only remaining logic is the Tracker signalling when the blobs are completed.

sources are:

• Syncing code
• RPC requests
• inbound GOSSIP
• local EL

If we trust local EL, and we apply the validation over all the sources, than it means this is feasable.

If we want to be paranoid, we could have a BlobSidecar to be an interface, the actual BlobSidecar will be BlobSidecarImpl and then we can have a ValidatedBlobSidecar type. The validation process will accept BlobSidecarImpl and produce ValidatedBlobSidecar. Then in the BlockBlobSidecarsTrackersPoolImpl we can only allow validated blobs to go in.

NOTE:
The availability checker has being designed when BlobSidecar wasn't having the inclusion proof. So we were forced to "postpone" the validation to the moment in which the block become available.

[tbenr]

WDYT @StefanBratanov @zilm13

[zilm13]

I agree, we are trying to avoid duplicate validations in PeerDAS too.
Syncing along with req/resp includes kzg proof and inclusion proof checks (which we miss, ouch https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md?plain=1#L343)
Instead of making ValidatedBlobsidecar, I'd add commitment/proof/blob check in createBlobSidecar, which pretty fast on verification and that's all.

[tbenr]

Instead of making ValidatedBlobsidecar, I'd add commitment/proof/blob check in createBlobSidecar, which pretty fast on verification and that's all.

Not sure it could end up being a clean solution.. we can have a chat on that.