Integration test for #5400

[hstove]

• Closes When a sortition is missed and the last miner hasn't mined a block, it doesn't create a TenureExtend transaction #5400

(hopefully eventually)

This PR currently just contains an integration test to try and reproduce the scenario described in #5400.

The basic flow of the test is:

• boot to nakamoto
• mine a regular block (A) (burn block with TenureChange)
• Have signers reject all new block proposals
• Mine a new BTC block (B) with a sortition
• Wait for the signers to reject it
• Mine a new BTC block (C) without a sortition
• Turn off the block rejection flag

I thought this would reproduce the issue, but things seem fine - the miner creates a TenureExtend off of block A and signers approve it.

[jferrant]

Still figuring out what we are trying to have happen, but I think this is directly related to this:
#5355 (comment)

[jferrant]

I think you might need to have 2 sep miners to get this to work. We need to

• boot to nakamoto
• Miner A mines a regular block A (burn block with TenureChange)
• Mine some stacks blocks ontop of Tenure A
• Turn on all block rejections
• Pause commits from Miner A
• Make Miner B win Tenure B
• Miner B should fail to mine anything
• Pause commits from Miner B
• Mine an EMPTY burn block (NO COMMITS)
• Turn off the block rejections
• MINER B SHOULD ATTEMPT TO TENURE EXTEND AND SOMEHOW SUCCEED (this is where we might need to make changes to the code to ensure it does do that.)

[hstove]

Yeah you may be right about needing 2 miners, but I swear this situation involved the same miner winning the first two blocks (though I should double check). I think it's also very possible that there was a different "root cause" in that case.