Test regression of syncing and replay with actual committed reference blockchain data

[arhag]

To be confident that changes do not unintentionally introduce changes the consensus protocol, we would like to add a new test (and testing utility) that checks for regression in compatibility of syncing and replaying reference blockchain data.

The test could store a reference blockchain (with QCs) generated and serialized (and committed to the source control) at some earlier point in time. Then it could read that blockchain into a nodeos (replay it) and use it as a source of blocks from which another nodeos instance can sync those blocks. The test should involve both a replay and sync to test both of those code paths in controller.

We would not normally commit that reference blockchain to source control. The test/utility could allow us to manually regenerate it if necessary, but we would really only need to do it once (or whenever we want to change the nature of the reference blockchain for the test case). Then the test, when it normally runs, just ensures it can validate that blockchain. However, it would be good for the test to generate the reference blockchain anyway, even though it is going to throw it away under typical use, just as an ongoing check in our CI to ensure the reference blockchain generation portion of the test does not break or regress.

This test (should be done with the Boost testing framework so that the generation of the reference blockchain is deterministic which provides multiple advantages. First, anytime we need to change the reference blockchain (which remember is binary data committed to source control), a reviewer could easily validate the changed data in a pull request by regenerating it themself locally. Second, it allows for the test to include a final check at the end where it compares the block ID of the reference chain it generates to the one that was in the source control to ensure they are the same.

Note that an early iteration of such a test was introduced as a verify_spring_1_0_block_compatibitity test as part of the work for #694. But that version did not write out block data to source control and test that syncing and replaying those blocks still worked. And it also did not provide a utility to easily persist the generated block data to source control if desired. It just generated the test blockchain and verified the last block IDs matched a hard-coded value. That was a good start. But this issue is to go further and implement the test/utility as is described in this issue.