Feat/signer track validation submission with config timeout

[jferrant]

Closes #5408

[kantai]

I'm a little wary of this change -- if the stacks-node is slow to respond to a block proposal, returning a rejection from the signer doesn't necessarily improve performance: the stacks-node is still going to be working on that proposal, and so the signer isn't really free to consider other proposals at that point.

[hstove]

I'm a little wary of this change -- if the stacks-node is slow to respond to a block proposal, returning a rejection from the signer doesn't necessarily improve performance: the stacks-node is still going to be working on that proposal, and so the signer isn't really free to consider other proposals at that point.

Probably a good point - would it be better to have the timeout on the stacks-node?

[obycode]

Probably a good point - would it be better to have the timeout on the stacks-node?

Yeah, that's a good idea. When processing requests, if it sees a block validation request from greater than X seconds ago (may need to add a timestamp in the request), quickly respond with an error code so the node doesn't spend any time doing the validation if the block is already too old.

But should the signer still have some mechanism to timeout if the node never responds? What if the node crashed and restarted and the request was dropped?

[jferrant]

Probably a good point - would it be better to have the timeout on the stacks-node?

Yeah, that's a good idea. When processing requests, if it sees a block validation request from greater than X seconds ago (may need to add a timestamp in the request), quickly respond with an error code so the node doesn't spend any time doing the validation if the block is already too old.

But should the signer still have some mechanism to timeout if the node never responds? What if the node crashed and restarted and the request was dropped?

I have created a ticket for this #5439

[obycode]

LGTM