Add Genesis NU, Update Canopy NU Testnet Height

[teor2345]

• Add a Genesis network upgrade, to handle genesis-specific consensus rules
• Add Testnet activation height for the Canopy network upgrade

These changes modify the same table, so I put them in the same PR.

Removed:

• Add a TestnetMinimumDifficulty network upgrade, to handle testnet-specific difficulty rule changes
  • Actually, this is a bad design, because it confuses network upgrades, and network-specific consensus rule changes. These changes need their own table and functions.

[oxarbitrage]

Looks good.

[daira]

I'm skeptical of the complexity trade-off here. There are only a small number of things that differ for the genesis block:

• the height-in-coinbase was missing (this was just a bug);
• there is no Founders' Reward output in the coinbase tx;
• the hashPrevBlock, difficulty adjustment, and median-time-past rules are special-cased.

[teor2345]

Hmm, good point. I'm not sure how we'll use the NetworkUpgrades enum yet.

But depending on the outcome of the parallel verification RFC in #763, we might have some additional Zebra special cases:

• there are no VerificationConstraints, because the genesis block is the first block (except, perhaps, that the genesis block is the first block to be committed to the state)
• There is no previous verification context
• the on-disk verification state is empty
• the verification context and on-disk state need to be initialised with empty values
• the verification context needs to be updated with the values from the genesis block, based on genesis-specific rules
• there are no chain tips in memory or on disk - the genesis block automatically becomes the first tip

See https://github.com/ZcashFoundation/zebra/blob/330f9b16154543cf17fd8a785b29a70b26b733da/book/src/designs/0002-parallel-verification.md#chain-context-and-network-upgrades

I think a lot of these special cases are covered by checkpoint verification, but we'll definitely need special handling for the on-disk state.

I'll review the need for the Genesis network upgrade after the RFC.

[hdevalence]

I think it still makes sense to have a distinct Genesis variant, because (unfortunately) the rules are actually different. Downstream code for whom this distinction doesn't matter can combine arms of a match statement, but not making the distinction at all means that we can't handle the differences in the rules in a principled way.

[daira]

Just wanted to make sure you'd thought about the complexity tradeoffs — sounds like you have.