Bypass locks for release packages builders on bb-* branches

[RazvanLiviuVarzaru]

TLDR;
Autobake builds on release branches can ignore Locks. This patch is an experiment for the next release (March-April). DO NOT MERGE BEFORE JANUARY RELEASE IS DONE.

Long-Story:
Although the bb-*-release release branches have priority when being selected from the queue, they are often blocked in the acquiring locks status, a mechanism meant to prevent overloading a host.

As a result, in most cases we need to manually stop other builds, thus freeing the hosts and allowing a release build to start. This is not guaranteed, however, because Buildbot may select a completely different builder to start on that host, often a non-release build, which causes the release build of interest to remain stuck in the same status.

This patch aims to remove this limitation by allowing builds that produce packages (autobake) to start on configured hosts regardless of the Locks value.

The risk of this patch is obvious: there is a possibility of overloading the host and causing the build to fail.

We can, however, try this approach and rollback during the next release if we discover that the failure rate caused by overloading the host exceeds the benefifs.

I am also relying on the fact that autobake builders are not memory-intensive but mostly CPU-bound, with parallel execution occurring only during the build phase, not when the packages are created.

[RazvanLiviuVarzaru]

@fauust and @grooverdan
I wonder what is your take on this approach. Are you onboard with this experiment?

I was mostly motivated by this. This (patch) is the least I can think of for now, because the other obvious action is to scale up the infra.

[fauust]

@RazvanLiviuVarzaru this is worth testing but it will be complicated to get clear results:

First of all, you might be missing some points regarding performance. Autobake builders also need good IO (at least this is my impression on deb packaging), since they produce quite a lot of artifacts. This would induce not only local IO but also network bandwidth since they need to store them on sshfs/nfs remote storage.

Also, having more builds running on the same hosts in parallel might result in slowing down the whole numbers of builds and end up taking more time (my experience is that serialization often speed up things, even if the host is not used at full capacity).

So, I am not saying that this should not be tested but I think that it's a very complex task to predict if it's going to help or not also given that there are lots of interactions between builders/runners.