Add a blob storage API to the coordinator

[kayabaNerve]

Tributaries publish DKG shares onto the blockchain so everyone has consensus on them. The blockchain doesn't need the DKG shares, it solely needs commitments to them (hashes). Then, the sender can make them available, and the receiver can request them explicitly.

This is further extendable to:

• Preprocesses. A 32-byte hash of preprocesses can be put on-chain, with only the participating signers requesting the blobs.
• Signature shares, as most shares will be larger than 32 bytes (as it'll be all shares for a transaction, not a single share for a single signature which would already be just 32 bytes).

And creates immense benefits if we ever adopt a tECDSA algorithm as those use t(t - 1) MtAs, which are quite large and each participant only needs one from each sender (not t - 1).

This may become further advantageous if any integrations needs long-running data. We can use blob storage to transmit blobs between instances of validator sets.

Please note DKG shares specifically may not be a good idea for this scheme as it risks a party being unable to recover their shares from the on-chain data.

[kayabaNerve]

Because data availability is an unattributable fault, we'd may need a force-on-chain function such that any validator can force a blob on-chain (requiring someone to publish it within some window of time), and the originating validator's lack of publishing makes them considered offline.

[kayabaNerve]

1) We should not use this for the DKG due to the share recovery properties (especially notable now thanks to #576). 2) We should use this for signing protocols. While FROST is just 64 bytes to preprocess and 32 bytes for a signature share, that's inconclusive to how we may sign for tens (if not hundreds) of signatures within a single signing protocol (one per input). Accordingly, we should even use it for FROST. I'd like to drop the inter-tributary concept for now. 3) Validators should only include a transaction citing a blob if they have the blob. Validators should consider a block temporally invalid if a transaction citing a blob is not locally present. This means the validators who commit to the block form a data availability quorom for all referenced blobs. 4) Syncing nodes should accept blocks with missing blobs. 5) We should prune blobs from completed signing protocols.