feat: prevent multiple block proposal evals

[hstove]

• Fixes [signer] Track 429 block submission failures in the database and resubmit them following a block validation response #5440

This PR adds a new table to SignerDB, which is used to track block proposal validation submissions that received a 429 (which happens when the node is already evaluating a proposal).

When a block validation response is received, the signer checks if there are any pending block proposals. If so, it submits the proposal for validation.

In a "one-node-many-signers" scenario, such as many of our integration tests, this doesn't result in the same proposal being submitted many times. This is because, when a block validation response is received by the signer, the signer checks if that block was marked as "pending" and removes it from the DB.

Note: opening in draft while I write an integration test

[jferrant]

Just the one comment really.

Also I apologize in advance as this will be not fun to test..

[obycode]

Looks great! Just noticed one potential optimization. Nice test!

[jferrant]

I think there are a couple of unused functions but LGTM

[hstove]

I'm going to try out this new integration test in develop and see if it does replicate the empty tenure behavior.

[obycode]

LGTM!

[hstove]

Good news - I've copy/pasted new_tenure_while_validating_previous_scenario into develop, and it fails as we'd expect it to! The failure happens from the test expecting signers to explicitly reject a block, which doesn't happen in develop.

[obycode]

🙌

Integration test added

[obycode]

@wileyj I've seen this ☝️ on a couple different PRs today. Any idea why that's happening?

[blockstack-devops]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.