blockchain: Early data commitment checks.

[davecgh]

This requires #3791.

This consists of a few commits that rework the early block process logic as follows:

• Separate the context free block data sanity checks from the header sanity checks
• Update the processing order semantics slightly to fully validate and index a previously unknown header before performing checks on the associated block data
• Make use of the recently-added historical positional agenda status determination to move the checks that ensure a given header commits to its associated block data very early in the block processing path
• Cache the merkle root proof to avoid recomputing and rechecking the merkle roots later in the validation path when they have already been definitively proven earlier

See the individual commit messages for more details.

Previously, the block sanity checks were performed before positional header validation and insertion of the header into the block index. This ordering coupled the header validation with block data validation and required callers to track whether header sanity checks had already been performed.

The new ordering gives header processing consistent semantics for both headers-first and full block processing. Namely, previously unknown headers are always subject to all context-free and positional header checks before being added to the index. Block data validation is then performed separately.

It also introduces a new block data precondition function that checks the necessary merkle root algorithms as one of the very first checks on block data. Since the new function runs before the full context needed to determine the state of a vote is necessarily available, it uses the historical positional agenda status determination when possible to reduce work. Otherwise, it must allow all possible algorithms and verify that the data matches the applicable algorithm later, once the agenda status can be definitively determined. Further, it returns a flag that specifies whether or not the data commitment is definitively known to be valid. A non-definitive agenda status cannot establish which merkle root algorithm is actually applicable.

Then, for cases where the agenda status can't be determined definitively in the earlier positional path, a new contextual merkle roots check function is introduced to take the place of the existing contextual check. This check is also reordered to execute just after the contextual header checks in the contextual block checks.

In practice, because the main and version 3 test networks now have historical agenda activation data specified, the correct algorithm will always be known early for those networks. In other words, invalid data will always be rejected early, and data that passes the early checks will be definitively known to have a valid data commitment.

[jholdstock]

Looks good other than that one comment.