Support shielded coinbase in getblocktemplate for Sapling addresses

[teor2345]

Motivation

Some miners use shielded coinbase, but it's pretty rare.

Specifications

• [Sapling onward] If effectiveVersion ≥ 4 and nSpendsSapling + nOutputsSapling > 0, then:
  – let bvkSapling and SigHash be as defined in § 4.13 ‘Balance and Binding Signature (Sapling)’ on p. 50;
  – bindingSigSapling MUST represent a valid signature under the transaction binding validating key bvkSapling of SigHash — i.e. BindingSigSapling.ValidatebvkSapling (SigHash, bindingSigSapling) = 1. [NU5 onward] As specified in § 5.4.7 ‘RedDSA, RedJubjub, and RedPallas’ on p. 90, the validation of the 𝑅 component of the signature changes to prohibit non-canonical encodings.
• The total value in zatoshi of transparent outputs from a coinbase transaction, minus vbalanceSapling, minus vbalanceOrchard, MUST NOT be greater than the value in zatoshi of block subsidy plus the transaction fees paid by transactions in this block.
• A coinbase transaction MUST NOT have any Spend descriptions.
• [Heartwood onward] All Sapling and Orchard outputs in coinbase transactions MUST decrypt to a note plaintext , i.e. the procedure in § 4.19.3 ‘Decryption using a Full Viewing Key (Sapling and Orchard)’ on p. 67 does not return ⊥, using a sequence of 32 zero bytes as the outgoing viewing key. (This implies that before Canopy activation, Sapling outputs of a coinbase transaction MUST have note plaintext lead byte equal to 0x01.)
• [Canopy onward] Any Sapling or Orchard output of a coinbase transaction decrypted to a note plaintext according to the preceding rule MUST have note plaintext lead byte equal to 0x02. (This applies even during the “grace period” specified in [ZIP-212].)

https://zips.z.cash/protocol/protocol.pdf#txnconsensus

Designs

• Accept encoded sapling and unified containing sapling addresses in the miner address config
• Create shielded outputs for miners using the Sapling address, according to the consensus rules
• In the z_validateaddress and z_listunifiedreceivers RPCs, validate Sapling addresses and return those fields

Related issues

See #5929

[teor2345]

We've been told by mining pools that no-one uses shielded coinbase, because it's expensive to generate the coinbase transactions.

We can re-open the ticket if a pool asks for it.

[teor2345]

We've been told some mining pools are using this

[mpguerra]

Hey team! Please add your planning poker estimate with Zenhub @arya2 @conradoplg @dconnolly @oxarbitrage @teor2345 @upbqdn

[teor2345]

Looking at the consensus rules, this is possibly a large ticket. Do we want to split it into Sapling and Orchard?

[teor2345]

@mpguerra I suggest we split this ticket into Sapling and Orchard/Unified Addresses before we start on it.

[teor2345]

Currently blocked by:

• PR change(rpc): Refactor get block template RPC into stages #5837
• Splitting this ticket into Sapling and Orchard/Unified Addresses

[mpguerra]

Currently blocked by:

* PR [change(rpc): Refactor get block template RPC into stages #5837](https://github.com/ZcashFoundation/zebra/pull/5837)

* Splitting this ticket into Sapling and Orchard/Unified Addresses

See #5929

[teor2345]

I deleted the Orchard-specific consensus rules from this ticket, because they are covered by #5929.