Introduce BlobsSidecar storage

[tbenr]

Introduces two new columns:

1. blobsSidecar column: store blobs for the entire lifecycle
   <Slot,BlockRoot> -> BlobsSidecar

2. unconfirmed blobsSidecar column: tracks which blobsSidecar conteined in the previous column is yet to be confirmed (which happens when the block is fully validated and imported)
   <Slot,BlockRoot> -> Void

Allows blobs to be streamed ordered by slot (ascending)

Introduces two pruning methods.

• One for unconfirmed blobs (will be used to prune unconfirmed blobs referring to finalized slots).
• Another for all (confirmed and unconfirmed) to be used to prune blobs outside our availability window (MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS)

Fixed Issue(s)

fixes #6586

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

[zilm13]

Some comments and question on usage

[zilm13]

A bit unclear what does this mean. Maybe BigEndianSlotAndBlockRootSerializer?

[zilm13]

I understand that core idea is to have a strream of it by slots, but it's not clear by this

[tbenr]

I added a comment on the class. I don't likeBigEndianSlotAndBlockRootSerializer :)

[zilm13]

I'm confused with this interface. What is a direction? What is start slot? Why do we need pruneLimit?

[tbenr]

it always start from the oldest, prunes up to endSlot but limits the pruning to maximum pruneLimit entries.
Naming endSlot differently might improve readability?

[zilm13]

So to answer, for example, on BeaconBlockAndBlobsSidecarByRoot we will need

1. Query DB for slot for each root
2. Query unconfirmed blobsSidecar for each pair to avoid it
3. Get BlobsSidecar for remaining pairs using this method

not sure that such complex flow is needed.
What are current cases we have with BlobsSidecar:
write:

• gossip receive (coupled, goes to import)
• sync receive (probably coupled too, in discussion, goes to import)

read:

• BeaconBlockAndBlobsSidecarByRoot (root list)
• BlobsSidecarsByRange (slot range)

delete:

• fork pruning (drop BlobsSidecars from noncanonical chain)
• every epoch remove 1 epoch blobsSidecars

Do I miss something or wrong with it? What potential future flows could we have with it?

[tbenr]

So to answer, for example, on BeaconBlockAndBlobsSidecarByRoot we will need

since we have to respond with a coupled block and blobs, we will start looking up blocks first. Once we have an existing blockRoot we can lookup in blobsSidecar without checking the unconfirmed column.

delete:

• fork pruning (drop BlobsSidecars from noncanonical chain)
• every epoch remove 1 epoch blobsSidecars

there is one more. The sequence will be:

• prune all blobs that has not being confirmed (related to blocks that remain in pending\future until discarded - ie never actually imported (successfully or with error))
• fork pruning (pruning blobs for noncanonical blocks up to the most recent finalized slot)
• prune blobs outside the data availability window (regardless finalization or not, just to avoid db overload when chain is not finalizing)

[zilm13]

LGTM