Optimize worker scheduling

[jugglinmike]

In the current configuration, workers may only make one collection attempt at a
time. A worker that is actively testing Firefox may be assigned a Sauce Labs
job, though. In that case, the job will be deferred until the worker is ready,
even if other workers become available in the mean time. When specific workers
are severely delayed (as was the case in gh-602), this can be very inefficient.

In the current implementation, fixing this seems to require deferring the
assignment of builds to workers. I'm not sure if this is possible with Buildbot,
but the need is clear, so we should look in to it.

[christian-bromann]

@jugglinmike I am happy to bump up the concurrency for the Sauce Labs accounts used by the WPT ci server to mitigate this problem.

[sideshowbarker]

@jugglinmike I am happy to bump up the concurrency for the Sauce Labs accounts used by the WPT ci server to mitigate this problem.

Let’s please do that. Whatever I can do to help make it happen, lemme know

[jugglinmike]

Thanks for the offer, Christian! This project uses Sauce Labs to provide the
daily test results for the Edge browser which are published on wpt.fyi. It is
not integrated with the web-platform-tests continuous integration service.

This problem in particular is caused by the behavior of Buildbot, but it's only
expressed when other failures introduce delays. Additional concurrency might
give us more time to react to those delays, but the scheduling problem
described by this issue will persist.