Only store the batch manifest

[peterbroadhurst]

A couple of important things have clicked into place:

• FIR-4 (rich query updates) and FIR-7 (DX manifests) integration to onchain-logic branch #403 - we added the concept of a manifest to a batch, so DX implementations can confirm what the received without needing to sign the whole massive payload of the batch
• Re-work batch logic for simplicity, efficiency, and restart recovery #501 - we made it so all message transfers include a batch, including unpinned
• Re-work batch logic for simplicity, efficiency, and restart recovery #501 - the batch logic only stores the batch at the end of the dispatch, as part of passing it to a transport plugin (IPFS/DX)
• When a batch arrives, we always store all of the contents of the batch individually - the messages and data

When you add all these together, the only reason you need to store the full batch is because the on-chain transaction contains a hash that is a function of the entire batch payload.

If instead we did the following small things:

• Include the TX type/ID in the manifest
• Include the batch ID in the manifest
• Make the hash of a batch, a function only of the manifest

... then all we would need to store is the manifest.

[peterbroadhurst]

Per hyperledger/firefly-fir#10 we need to make sure that the new code that generates an IPFS/DX payload for the batch, is verified to always generate the same binary payload. Even if the batch is generated multiple times.

This means a couple of key things:

1. Do not include mutable fields of messages/data in the batch payload
2. Do not allow fields in the batch wrapper itself to be mutable (timestamps etc.)

To do this, I think the batch needs to be assembled with a field by field include-list approach, rather than an exclude-list approach. So if Message/Data etc. end up with new fields in the future - there's no possibility of forgetting to update an exclude-list.

[peterbroadhurst]

In review of #517 I noticed we're storing the full manifest on the private batch operation, but we don't need to as it can be generated from the batch (and soon will be the thing stored on the batch).