Rework EffectHash

[redshiftzero]

This is a tracking ticket for modifying the EffectHash:

• Refactor TransactionBody such that its component pieces can be incrementally hashed (e.g. by a hardware wallet): Refactor TransactionBody to include a TransactionParameters #2784
• Combine those fields into the full transaction effect hash e.g. H(fixed size hashes of per tx data packets || num actions || fixed size hashes per action)
• Use the protos to encode the effect hash for individual actions: Change EffectingData implementations to hash the proto encoding of the body #2000, ensuring for each action that where needed the current data modeling separates the effecting data (e.g. SpendBody vs Spend), and that only that field is included in the effect hash - crypto: rework action-level EffectingData implementations #2931

[conorsch]

Raising priority on this ticket, moving to top of Next column. We still need more discussion on design. The motivation for this work is to reduce the likelihood that a developer will overlook these interfaces and thereby introduce bugs; see for example https://github.com/penumbra-zone/penumbra/pull/2820/files.

[cronokirby]

Some ideas after more discussion with @redshiftzero:

• For handling padding, we could use a similar api to the GroupHasher utility we've just introduced for the setup ceremony code.
• For handling ordering of items we need to include in the effect hash (like the recent PR in fix ics20 withdrawal: include withdrawals in effect hash and tx builder #2820), one solution would be to hash all of the items, and then sort the hashes, before including those in the hash state. This would provide a canonical total ordering for any item that can be hashed, and thus avoid the need to worry about having a consistent ordering elsewhere in the code. Not sure if that's totally solving ordering, but seems to move the issue away from the effect hash side of things.
• For handling code reuse with proto serialization, the tricky part is when a structure mixes both "atomic" fields (string, ints, etc.) and composite substructures that need to be hashed. The issue is that we can't then just hash the serialization of the struct, because the sub-structures need to be hashed first. One way around this, that requires touching many protos, would be to make it so that each structures is always either a collection of sub-structures, or a collection of atomic fields. This would mean that the only two codepaths would be hashing all sub-structures before combining those hashes, or serializing the entire structure as a protobuf and hashing that.