Feat/block rejections timeout heuristic

[rdeioris]

Description

This patch modifies the logic of miner timeout while waiting for signer confirmations/rejections.

The current behaviour is to wait indefinitely until the threshold is reached (for both rejections and confirmations) or the burnchain tip changes or the block is found in the staging db.

The new behaviour adds heuristic for introducing a timeout (instead of waiting indefinitely and in addition to the threshold checks) that decreases based on the amount of rejections.

Note that if the initial timeout (the one set at the start of the cycle) expires without having rejections, the old behaviour of retrying from scratch is still valid. (eventually the other mechanisms, like the change of the burnchain tip will kick in as before)

Applicable issues

• fixes Miner should abort waiting for proposals #5705

Additional info (benefits, drawbacks, caveats)

Note that the original code was set to trigger the conditional variable of the waiting cycle only when reaching the threshold (in confirmations or rejections). Now it is triggered at every update to move the logic of timeout in the block proposal final part ( get_block_status() )

The integration test is based on a test-only static var BLOCK_REJECTIONS_CURRENT_TIMEOUT, that gets updated with computed timeout value based on rejections.

Checklist

• Test coverage for new or modified code paths
• Changelog is updated
• Required documentation changes (e.g., docs/rpc/openapi.yaml and rpc-endpoints.md for v2 endpoints, event-dispatcher.md for new events)
• New clarity functions have corresponding PR in clarity-benchmarking repo
• New integration test(s) added to bitcoin-tests.yml

[kantai]

So, I think a better strategy might be to just define a stepping function.

Like,

let reject_threshold = self.total_weight.saturating_sub(self.weight_threshold);
let block_rejection_timeout_steps = BTreeMap::from([
   (0, 600),
   (reject_threshold / 3, 300),
   (reject_threshold * 2 / 3, 150),
   (reject_threshold, 0)
]);

let rejection_timeout_secs = block_rejection_timeout_steps
     .range((Included(0), Included(rejections)))
     .last()
     .ok_or_else(|| NakamotoNodeError::SignerCoordinatorFailure("Invalid rejection timeout step function definition".into()))?;

Then, I think we just make that all configurable via the node configuration -- that way we don't need a test static.

[rdeioris]

So, you would like to have 3 config parameters for the signer for each of the thresholds ? or you would prefer a single array-like option where you define each step ? (so you can have more than 3, or 1 eventually).

[kantai]

Yeah -- I think a single array-like option.