Fix storage DOS attack in block proposals

[ma2bd]

We should not persist any certificate value (or blob) in storage before a block is confirmed.

Staged execution should behave silently differently from real execution by accepting to read certain certificate value (soon to be blobs) from a local in-memory map instead of storage.

Incidentally, we should tag the content of such map as used and verify that all of them are used after the fact, instead of making a pass where system operations are introspected. (This won't work for user blobs)

Also, when handing a block proposal, we shouldn't put the blobs into storage yet. And when handling a confirmed block certificate, we should only put them into storage after the execution.

[afck]

I don't think this is 100% completed yet:

We add to ChainManager::pending_blobs whenever we vote for a proposal. But a malicious client could make us vote for any number of block proposals without having them confirmed.

We need a rule for the pending blobs in the chain manager that guarantees liveness without allowing clients to add an arbitrary number of pending blobs.

The only rule I can think of is:

• The chain manager should always contain exactly those pending blobs that belong to the locked block.

All other pending blobs should go into a limited LRU cache.

[afck]

Currently a lot of invalid block proposals with new blobs can fill up validators' value caches.

Maybe there should be a separate per-chain cache for the blobs that haven't been confirmed yet.

[ndr-ds]

Should be done after #2704 is done

[ndr-ds]

Actually, we probably need to finish #2186 also

[ndr-ds]

We still need to add a limit on the total size of a block proposal (including blobs). Talked with @afck, we were thinking maybe 13 MB? Ideally once we can stream from the client to the server (after gRPC Web adds support to it), we'll be able to just stream the blobs in the proposal over and hopefully the blob limits would be enough.