Support uploading blobs separately

[afck]

Blobs can be big, so they shouldn't have to share a gRPC message with each other or with a block. For downloads to the client, we can use gRPC subscriptions and stream them, but for uploads we cannot use them because of the web client.

When uploading a confirmed block certificate that uses blobs, the server cannot execute it if blobs are missing. It can, however, note in the blob state in storage that it now has seen proof for these blobs. So the client can now, in one message per blob, upload the blobs, and then re-upload the certificate.

When uploading a block proposal, the read blobs must already be available anyway (otherwise the client has to send them together with proof, which is already implemented). For the published blobs, validators could simply sign the proposal even if they don't have them yet. Once the client has the confirmed block certificate, it can use the above method to upload the certificate and the published blobs.

[afck]

With #3108, this is solved for confirmed blocks.

For block proposals, we do want to have the published blobs available at validation time, to check their size. And for validated blocks, we want to avoid storing the blobs in the chain manager, but also can't write them to storage yet.

So we add to the chain state (as views; shown as simplified types here):

• pending_validated_blobs: Option<(ValidatedBlockCertificate, Map<BlobId, Option<Blob>)> with the validated block in the current round if it's still missing blobs.
• pending_proposal_blobs: Map<Owner, (BlockProposal, Map<BlobId, Option<Blob>>)> with any pending proposals and their sets of published blobs. (Each owner is only allowed to make one proposal at a time. If the proposal is a re-proposal, all required blobs are included.)

Both fields are cleared whenever a new block height is reached and the chain manager is reset. The chain manager becomes a view with subviews, and the blobs belonging to the proposed resp. locked block become a MapView, too.

There is a new endpoint UploadPendingBlob(ChainId, BlobContent) that adds the blob to pending_proposal_blobs and pending_validated_blobs wherever it matches, handles any that now have their complete set of blobs, and then returns the ChainManagerInfo. So clients can now:

• First upload their proposal/validated block.
• Then upload all the blobs that belong to it.

Conversely, if a client receives a chain manager with a proposal or a locked block that they are missing blobs for, they request it with a new endpoint DownloadPendingBlob(ChainId, BlobId), which looks up the blob in locked_blobs and proposal_blobs. (Not in the "pending" fields.)

These changes should be done in two separate PRs:

• Make locked_blobs and proposed_blobs separate MapViews, add a DownloadPendingBlob endpoint; do staged downloads.
• Add pending_validated_blobs, pending_proposal_blobs, and an UploadPendingBlob endpoint; do staged uploads.
• Check total published blob size already in the pending_proposal_blobs field. (Only for new proposals!)