Replace active_finalizer_policy_digest with last_pending_finalizer_policy_digest in finality digest computation

[arhag]

Change the active_finalizer_policy_digest used in the calculation of the finality digest to instead be last_pending_finalizer_policy_digest. This is the digest of the finalizer policy (which includes the generation number in it) with the greatest generation number in the history of the blockchain so far that is not in the proposed state (so it is either in the pending or active state). This is something that should always be determined from the block_header_state. For efficiency reasons, it will probably be worth caching the last_pending_finalizer_policy_digest in the block_header_state and ensuring it is updated as necessary when producing the next block_header_state.

This change supports IBC by allowing a proof to be provided to the IBC contract for the contents of a new proposed finalizer policy associated with a particular generation number so that it can then later be used for validating QCs on a block that uses that finalizer policy as the active finalizer policy.

The active finalizer policy generation number used separately in the calculation of the finality digest should still remain as is. That is always the generation number of the finality policy that is active for the block, i.e. the one to be used for validating the votes in the QC for that block.

So, in summary, the finality digest would be defined as follows:

The finality digest is the SHA256 digest of a serialization of a structure that is versioned according to the light header protocol version (this is a new versioning scheme consisting of major and minor version numbers that is separate from protocol features that only gets updated if a protocol feature causes a breaking change to light block header validation). For now the only light header protocol version supported is 1.0. The serialization should include that major version number 1 (as a 32-bit number), the minor version number 0 (as a 32-bit number), and the rest of the serialization of the versioned structure.

That version structure for the version 1.0 protocol consists of the active finalizer policy generation number followed by two digests. The first digest is the Finality Tree Root of the block which is returned by the new finality_mroot() function added to block_header_state. The second is a digest computed as the SHA256 hash of the serialization of two other digests: the last_pending_finalizer_policy_digest and the base_digest.

The last_pending_finalizer_policy_digest is the SHA256 hash of some serialization of the last pending finalizer policy in the history of the blockchain so far. Note that if there are no pending finalizer policies in the queue, then the last pending finalizer policy is the active finalizer policy.

The base_digest is the SHA256 hash of some serialization of the remaining (non-cached) fields of the block_header_state. So this includes: header, core, finalizer_policies, active_proposer_policy, proposer_policies, and activated_protocol_features.