x/build: builds waiting on resources shouldn't be in building state #10716
Description
The reverse BuildletPool impl is cheating a bit or interacting weirdly with the rest of the coordinator: instead of blocking on returning a buildlet, it instead "starts" a bunch of builds even if there's not an idle iPhone available. And then each builds looks like it's in progress on build.golang.org (with happy blue gopher), but in reality they're all just stuck, for 4 hours (!?) here:
Arguably, the GCE pool impl might do this too, but it happens much less often so it's been easier to miss and ignore.
We should have make quota a more first-class concept within the coordinator and have different states for "waiting" vs "building". And when quota becomes available, we should prioritize which waiting build gets to go next. Right now the one who gets lucky and grabs a mutex gets to go next.
Then, once we have two states, we should make build.golang.org have two colors of gophers: gray for waiting, and blue for actively building.