PVF: drop backing jobs if it is too late

[AndreiEres]

Fixes #5530

This PR introduces the removal of backing jobs that have been back pressured for longer than allowedAncestryLen, as these candidates are no longer viable.

It makes sense to expect a result for a backing job execution within allowedAncestryLen * 6s. Since the execution time is not zero but within the range of 0..exec_timeout, we optimize the dropping by subtracting a time sufficient for job execution: allowedAncestryLen * 6s - min_exec_time. The min_exec_time should fall within 0..exec_timeout and represents the minimum observed execution time.

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable 2/3
Logs: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7288338

[s0me0ne-unkn0wn]

What if, during the waiting period, Babe misses a slot or two and block times elongate? Will we discard a viable candidate, then? And do we care?

[AndreiEres]

What if, during the waiting period, Babe misses a slot or two and block times elongate? Will we discard a viable candidate, then? And do we care?

That's a good question.

Do you mean a situation where a candidate should have been dropped under normal circumstances, but due to a BABE failure, received a chance to be backed? I would say under normal circumstances we have enough time to execute the job. If we have delayed it for so long, it means we're overwhelmed. Dropping this lucky candidate will have more impact than not dropping them in my opinion.

[burdges]

What if, during the waiting period, Babe misses a slot or two and block times elongate? Will we discard a viable candidate, then? And do we care?

We hopefully do not care much. In fact, we should explore back pressure in block production too, meaning a relay chain block producers drops some backing statements because they believe the network to be overloaded. A dispute or implicit escalation could be "paid for" by delaying like 30 candidates for example.