Allow CompactSize to be used for non-length fields (addrv2 and ZSEs)

[teor2345]

Motivation

In #2155, we reject CompactSizes greater than the maximum network message length, as a memory DoS defence-in-depth.

But some ZIPs use CompactSize for counts and ids that are not array lengths.

We might want different compact size types for array lengths, and for non-length values.
We could split the CompactSize into:

• CompactSizeMessage(u32): limited to the maximum protocol message length (currently 2MB), and
• CompactSize64(u64): limited to 8 bytes

Specifications

The following ZIPs use CompactSize for counts and ids that are not array lengths:

• addrv2 message: https://zips.z.cash/zip-0155
• FlyClient - Consensus-Layer Changes - Chain History: https://zips.z.cash/zip-0221
  • the FlyClient serialization is implemented by the zcash_history crate, not Zebra
• Transparent Zcash Extensions (TZEs): https://zips.z.cash/zip-0222
• Transaction IDs and Signature Validation for TZEs: https://zips.z.cash/zip-0245

Alternative Implementations

We could just use librustzcash for these ZIPs, treat its data as opaque, and inherit its CompactSize limits.

Some parts of librustzcash and zcashd currently have a 32 MB limit, inherited from bitcoin.

[dconnolly]

never have more than 2 million blocks

This is likely to happen within the next year or so 😬

[dconnolly]

We should split the CompactSize into:

• CompactSizeLength(u32): limited to the maximum protocol message length (currently 2MB), and
• CompactSize64(u64): limited to 8 bytes

Could we make these variants of a CompactSize enum?

[teor2345]

never have more than 2 million blocks

This is likely to happen within the next year or so 😬

Around September 2022 on testnet, if there is no testnet rollback.

We should split the CompactSize into:

• CompactSizeLength(u32): limited to the maximum protocol message length (currently 2MB), and
• CompactSize64(u64): limited to 8 bytes

Could we make these variants of a CompactSize enum?

An enum isn't type-safe, so we could accidentally:

• use a large invalid size for a message length
• panic because we're checking the protocol message length limit, but the field isn't a message length

So we need separate structs for each type.