Add transaction version 5

[oxarbitrage]

Motivation

Start the work in the next network upgrade transaction.

Solution

Add the V5 transaction to the enum and add some common fields that we know are going to be there. The "rest" of the transaction is represented in as Vec<u8> in a rest field.

The prop tests are blocked on #1823

The code in this pull request has:

• Documentation Comments
• Unit Tests and Property Tests

Review

Related Issues

Closes #1822
Closes #1826

Follow Up Work

[teor2345]

Looks like a good start, but needs some fixes.

Here's what I checked:

• version group id
• other consensus rules
• serialization and deserialization
• all instances of V4 in the codebase, to make sure we added a matching V5

Here's what I suggested:

• the specific change and ZIP for each unimplemented!()
• add unimplemented!() instead of re-using v1-v3 code

Here's what I committed to your branch:

• update comment for V5 transactions 0ac10e2
• add V5 transactions to non_finalized_state 5269c2e
• add ZIPs to unimplemented messages c1af4a6

Here's what we still need to do:

• Make the version group id match the draft spec (typo)
• Add zcash_deserialize implementation for version 5
• Make Transaction::sprout_nullifiers explicitly return empty for V1 and V5
• Add a V5 case to Transaction::sapling_nullifiers
• Double-check all instances of V4 in the codebase

Here are the follow-up tasks we should do:

• Use v5_strategy in Arbitrary for Transaction Use v5_strategy in Arbitrary for Transaction #1826
• Work out how to create V5 transactions before the NU5 activation height is set Use v5_strategy in Arbitrary for Transaction #1826
• Split WrongVersion errors into OutdatedVersion and PreActivationVersion Split WrongVersion errors into OutdatedVersion and PreActivationVersion #1827
• Use PreActivationVersion for V5 if NU5 hasn't activated yet Split WrongVersion errors into OutdatedVersion and PreActivationVersion #1827
• Parse Sapling data in transaction version 5 Parse Sapling data in Transaction Version 5 #1829

Here is a low-priority optional follow-up:

• Move some code into methods on Transaction Move duplicate Transaction code into methods #1828

[teor2345]

Now that we've split off the Arbitrary impl into #1826, this PR doesn't depend on NU5 (#1823) any more.

[teor2345]

Please check any copied code against the draft NU5/Orchard specs.

There are a lot of small changes to field orders, constants, and other protocol features.

[teor2345]

Similarly, the order of these fields should match the draft v5 transaction spec.

[teor2345]

Looks great, we just need to:

• update the field order in v5_strategy, to avoid a nightly clippy lint
• double-check all instances of V4 in the codebase

[teor2345]

Hey @oxarbitrage we're almost there.

I made the following changes:

• We're still deciding if V5 transactions support Sprout, so I changed all the V5 sprout match arms to unimplemented!()
  • This part of the spec is still changing
• I found another match without a V5 arm, looks like we both missed that one

I just need you to:

• Check the changes I just pushed
• Double-check all instances of V4 in the codebase, to make sure they have a matching V5
  • Unfortunately, IP addresses also have a V4 variant - we don't need to fix those

[oxarbitrage]

Last changes are all ok. Double checked V4/V5 instances, they are all good after 48fb77e