[TGE] BFT state snapshots to PoW chain

[mareksepp]

Prepare the PoW node implementation to receive state snapshots from the BFT cluster and include them in the block headers.
More detailed request added below in a comment below.

[ahtotruu]

Some specification and implementation work has been done in the https://github.com/unicitynetwork/unicity-pow/tree/%40cryptohog/merkle branch of the (now obsolete) https://github.com/unicitynetwork/unicity-pow/ repository that needs to be reviewed and merged/ported to the current https://github.com/unicitynetwork/unicity-node/ repository.

In particular, see the updated block header specification and the rules for computing the snapshot commitment to be included in the block header.

[ahtotruu]

Amend the PoW node implementation to bring back the block payload and populate it as follows:

1. For each block the node tries to mine, it generates a token ID for the (potential) block reward. Note that the token IDs for all successfully mined blocks must be distinct. The easiest way to achieve this seems to be to generate a new (pseudo)random ID for each attempted block. The IDs must also be unpredictable to any outside party. Thus generating them by iteratively hashing some seed value is not good but generating them by hashing a seed+counter value, for example, would be OK. See Sec 6.1.6 Mining of the YP for more details.
2. For each block the node tries to mine, it obtains the latest Unicity Trust Base record from the BFT cluster. Each new record needs to be authenticated before accepting it. If there is no new UTB record (the latest UTB record has already been published in a previous PoW block), the value remains blank. See Sec 6.2 Snapshot Publishing of the YP for more details.
3. The PoW node adds the root hash of the 2-leaf Merkle tree built on the two previous items to the block header before passing the template on to the miner process. See Sec 6.1.4 Block Structure of the YP for more details.

To enable the owner of the node to mint their reward tokens, they need a way to access the token IDs for all successfully mined blocks. Eventually the minting process should be automated, but for the scope of this task, a CLI option to just list the token IDs for recent successfully mined blocks (along with the corresponding block heights and hashes) is sufficient.

[ahtotruu]

It has been decided that bringing back the full BTC payload machinery would be overkill due to the relatively small size of the block payload data (for example, with 1-week epochs and 15 BFT validators, the annual UTB records would take up ~75KB with individual ECDSA signatures and ~40KB with BLS signatures) compared to the headers (with 2.4-hour block time, the headers themselves amount to ~400KB annually).

Instead, the payload will be just appended to the block headers. For storage and transport purposes, it will look like the headers are variable-sized. In all blocks, the hash of the target token ID will be appended to the headers. In blocks with a new UTB record, the record will then be appended to the hash of the token ID.

Payload pruning will not be implemented initially. However, to maintain the possibility for future, only the 112-byte static part of the headers will be hashed for mining and linking of blocks. Note that the static fields contain the root hash of the 2-leaf Merkle tree built on the target token ID and the UTB record, so the integrity of those fields can still be verified against the headers when the extra fields are present (or when they are obtained by some other means to complement a pruned ledger).