Create a Savanna version of forked_tests

[linh2931]

There are significant differences in fork handling between Legacy and Savanna. Instead of trying to make the same forked_tests work for both Legacy and Savanna, it is simpler to create a separate version for Savanna.

[greg7mdp]

Status for forked_tests.cpp

"irrblock"

=> Works in both legacy and savanna modes.

"fork_with_bad_block"

This test would be difficult to adapt to Savanna consensus. Leaving as-is.

Testing scenario from this test to possibly duplicate for savanna:

• split the network (so finality doesn't advance) and create 7 forks on a node, each branch containing 7 blocks, each having a different block corrupted (block index 9 to 7)
• blocks are corrupted by changing action_mroot, which allows them to be inserted in fork_db, but won't validate.
• push forks to other node, most corrupted fork first (causing multiple fork switches)
• produce blocks and verify that finality still advances.

"forking"

This test is very specific to legacy mode. Leaving as-is.

Testing scenarios from this test to possibly duplicate for savanna in issue #10 :

• A fork is created where some producers are on one branch (held by one node) and the rest are on another (held by another node). LIB is not expected to advance on either node. When the blocks are sent to each other, the forks resolve to pick the better chain and then LIB begins advancing.
• Verify producer schedule change occurs as expected. (We do not need to duplicate this exact scenario in new test since there is some coverage of this in separate Savanna-specific tests. But we want to augment those tests with a test case in which we see proposer policies change independently on the two different partitioned branches, and then we see the forks resolve correctly.)
• Testing a trigger for some old fork DB bug to make sure the bug still does not exist. (It is not clear what this bug is but is very unlikely to be relevant for the new fork DB code used for Savanna. So there is no need to replicate this test case for Savanna.)

"prune_remove_branch"

This test verifies that the fork-choice rule favors the branch with the highest last irreversible block over one that is longer.

=> will create a Savanna specific version which verifies that both block_state::last_final_block_num and block_state::last_qc_block_num are taken into account before block_state::timestamp.

"validator_accepts_valid_blocks"

=> Updated to run in both legacy and savanna modes.

It doesn't seem to me that the test does test what it says it does. Also has nothing to do with forking.

"read_modes"

=> Updated to run in both legacy and savanna modes.

Has nothing to do with forking.

"irreversible_mode"

This test is specific to legacy mode, as it depends on how long it takes for blocks to becomme irreversible. Leaving as-is.

Testing scenarios to duplicate for savanna in issue #10 :

• A node not in irreversible mode captures what the LIB is as of different blocks in the blockchain. Then the blocks are synced to a node running in irreversible mode gradually. When syncing up to some block number, the test checks that the controller head is at the block number of the corresponding LIB that was captured earlier.
• Two nodes not in irreversible mode are used to construct two competing branches. One branch is considered the better branch compared to the other. The LIB determined from the better branch is a descendant of the LIB determined from the worse branch. Then a third node in irreversible mode gradually receives blocks from the two nodes. It first receives the worse branch and the test checks the LIB is what is expected. Then it receives the better branch and the test checks that the LIB has advanced to the new block number expected which indicates that the fork DB has recognized the new branch as the better branch. Also verify that the a block from the worse branch that was not in the better branch has been pruned out of the fork database after LIB advances past the fork block.

"reopen_forkdb"

=> Updated to run in both legacy and savanna modes.

Not clear to me what exactly this tests?

"push_block_returns_forked_transactions"