Feat/get pox addrs

[jcnelson]

This PR implements #3155 by adding get-burn-block-info? pox-addrs <burn-height> to Clarity. It returns an optional tuple with two items:

• addrs: The list of up to two PoX addresses (type (list 2 { hashbytes: (buff 20), version: (buff 1) }))
• payout: The number of burnchain tokens (i.e. satoshis) paid to each PoX address across all block-commits (type uint).

It returns (some ..) when the sortition for burn-height is in the transaction's Stacks block's fork, and none if not.

Burn addresses are not reported. This method will return an empty addrs list during the reward phase if the BTC are to be burnt, and will return an empty addrs list during the prepare phase.

The payout value is per TX output. During the reward phase, there are two outputs whose values are equal to half of the node's burn_fee_cap. This is true even if there are no more PoX reward addresses to pay. During the prepare phase, there is one output, and its value is equal to the node's burn_fee_cap. So for example if the network is spending 10,000 sats per block-commit, then payout will be 5,000 during the reward phase and 10,000 during the prepare phase.

In addition to implementing this feature, this PR replaces the use of StacksAddress to represent Bitcoin transaction outputs with a similar PoxAddress structure. This structure captures all of the fields in a pox-addr argument to stack-stx or delegate-stack-stx, which is not recoverable from just the Bitcoin chain state. It is these values that are passed back to the caller from get-burn-block-info? pox-addrs.

The addition of PoxAddress is not only necessary to represent the full PoX address data, but also lays the groundwork for implementing segwit (and taproot) addresses. These addresses cannot be represented in a StacksAddress, but because PoxAddress is an enum, we can later add type variants that represent any scriptPubKey we want.

[codecov[bot]]

Codecov Report

Merging #3245 (7f5af6b) into next (43b3398) will increase coverage by 25.47%. The diff coverage is 86.29%.

@@             Coverage Diff             @@
##             next    #3245       +/-   ##
===========================================
+ Coverage   58.31%   83.79%   +25.47%     
===========================================
  Files           1      277      +276     
  Lines         571   227403   +226832     
===========================================
+ Hits          333   190551   +190218     
- Misses        238    36852    +36614     

Impacted Files	Coverage Δ
clarity/src/vm/test_util/mod.rs	51.29% <0.00%> (ø)
src/burnchains/mod.rs	89.59% <ø> (ø)
src/chainstate/burn/operations/mod.rs	46.04% <ø> (ø)
src/chainstate/stacks/boot/contract_tests.rs	94.44% <0.00%> (ø)
src/chainstate/stacks/db/transactions.rs	97.97% <14.28%> (ø)
src/clarity_vm/clarity.rs	94.82% <14.28%> (ø)
.../chainstate/burn/operations/leader_block_commit.rs	95.21% <45.45%> (ø)
src/chainstate/burn/db/sortdb.rs	94.42% <73.44%> (ø)
.../chainstate/burn/operations/leader_key_register.rs	96.08% <75.00%> (ø)
src/chainstate/stacks/db/blocks.rs	89.56% <75.00%> (ø)
... and 303 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

[jcnelson]

I think I might want to update the API for this to return the burn addresses as well (so then it's obvious how much total BTC was spent, given the per-output spend)

[jcnelson]

Need to make the return type easier to understand:

• Return burn addresses explicitly
• Return burn addresses in the prepare phase, so that the number of entries in the list reflects what block-commits are actually doing (so it's easier to interpret the payout field)

[jcnelson]

Okay, the above is done. cc @kantai @gregorycoppola @pavitthrap for review/approval.