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
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