Create a dep-wait Wait task and a retry-with-depwait event reaction
Split from #374 (closed) following design discussion
Due to lack of time, we implemented first a simple "retry-with-delays" strategy (in #497 (closed)). In the future, we probably want to have something smarter where build failures due to missing/broken build dependency are handled differently.
The proposal is to add a new event reaction retry-with-depwait that detects when the build failed due to build dependencies issues. It would then auto-retry the task but block it on a new DepWait Wait task. That task would complete only when the build dependencies are known to be installable.
The expectation is that some periodic task in debusine would regularly go through all those running DepWait task, group them when possible (i.e. when they check against the same target distribution) and check whether the dependencies are now installable. (It's not yet defined whether that periodic task is something internal or some standard workflow that would have to be setup by the user. That periodic task might possibly leverage dose-builddebcheck.)
The associated UI for DepWait task should likely offer to the user to force the completion of the task so as to be able to manually unblock the build request when the automatic process fails in some ways (example of a case that might not be trivial to detect).
The DepWait task should also have some timeout so that if the build dependencies never get installable, the task gets marked as failed and the sbuild task gets aborted.
Much like with the retry-with-delays event reaction, there should be some upper limit to the number of retries and possibly some minimal delay before the Wait task gets completed (so that retries are not scheduled one after the other, this is for case where the logic would incorrectly consider that the build dependencies are now installable).