When a new burn block is mined; fast blocks should stop progressing (Integration)

To check:

• tenure height updated + 1
• next_block_consensus_hash != current_block_consensus_hash
• submit burn block -> imediately submit a tx, then wait 5 secs, then new tx.
  • check /v2/info / or most recently process blocks.
  • good cases:
    • 1 old consensus hash and 1 new consensus hash
    • both 2 new consensus hash
  • bad cases:
    • both 2 old consensus hash

TODO: Integration tests that should try the above cases
Look into: multi-miner integration tests
Stall nakamoto-runloop:

• Test 1
  • Miner A and B -> when Miner A won the right to mine the tenure
  • call miner B runloop to stall
  • 80% signers look into miner B -> all signers don't see the update
  • Miner A will try to mine blocks but will not be able because the signers don't see them
  • => miner and signers don't update block

• Test 2:
  • Miner A and B -> when Miner A won the right to mine the tenure
  • call miner B runloop to stall
  • All signers look into miner A -> all signers see the update
  • => only miner B doesn't update blocks, the signers and miner A update
  • unfreeze miner B and see if he catches back with the miner A progress
    • inventory sync - when will it try to re-sync
    • can survive a restart and continue mining?