Feat: wait for outstanding proposals

[kantai]

Description

This PR adds a new heuristic to the nakamoto miner: on the first block of their tenure, if it sees an outstanding proposal from the parent tenure, it will wait a configurable amount of time for the signer set to confirm that proposal and process it. This check occurs before the miner begins block assembly.

[kantai]

Marking as a draft for now while I try to figure out the best way to test this!

[hstove]

@kantai I think the main "blocker" here is that the previous miner is going to hit the BurnchainTipChanged error, and thus abort trying to complete the final block in its tenure. So... should the previous tenure's miner use the same "timeout" to try finishing its block?

[kantai]

@kantai I think the main "blocker" here is that the previous miner is going to hit the BurnchainTipChanged error, and thus abort trying to complete the final block in its tenure. So... should the previous tenure's miner use the same "timeout" to try finishing its block?

Hmm -- in the normal mining behavior, whether or not the previous miner hits the BurnchainTipChanged error shouldn't matter. The way that this patch works is that the current miner just checks if there's an outstanding proposal already in the stackerdb with a block height >= their current block height. If the current miner doesn't see such a proposal, they'll just start mining. If such a proposal exists, the prior miner may have indeed interrupted from their signature gathering, but the signer set may still be in the process of approving it. If the signer set approves it, they'll broadcast it themselves anyways.

[obycode]

This approach looks good to me!

[hstove]

Ok, I've got a new signer test that verifies this behavior as working! Ready for review

[obycode]

🙌

[jferrant]

No issues with the code, but if you could run clippy on the stacks-node and on libsigner would be awesome.
Also some conflicts need to be addressed.

for e.g. cargo clippy -p stacks-node --no-deps --tests --all-features