Miner should generate a tenure-extend and continue mining if the next miner does not start mining

[obycode]

Currently, the miner will generate a tenure-extend and continue mining if there is no sortition in the next burn block, but it should also do this if there is a sortition, but the next miner does not mine a block within some threshold time.

[obycode]

Sometimes, the next miner is unable to mine any blocks, so the previous miner should be able to tell for sure that it can extend its tenure. This happens if the winning miner's block commit is not committing to the correct tenure. Sometimes this will happen if a miner's block commit is not RBFed in time. #5064 could help with this, avoiding the need for an RBF.

[obycode]

If a miner sees that the next miner is in this situation, it should go ahead and immediately submit a tenure extend.

[obycode]

I think this scenario is happening often currently in mainnet, causing pauses in block production. One example I looked at:

• 1730421788.150710: 868333 arrives
• 1730421788.918551: Miner submits a block commit committing to 179741
• 1730421790.755410: Tip advances to 179746
• 1730421792.239285: Miner builds 179746'
• 1730421811.364948: Signers reject 179746' because the last miner built 179746 already
• 1730421812.605401: Miner builds 179747
• 1730421824.720642: 179747 is approved and tip advances
• 1730421825.640789: attempt to RBF block commit, committing to 179747
• 1730421849.696787: burn block 868334 arrives, including the original block commit