x/build: builds waiting on resources shouldn't be in building state

[bradfitz]

/cc @crawshaw @adg

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.

[minux]

A related problem of the current design is that the next commit that gets the machine is non-deterministic. We should apply weights to the waiting builds so that the most recent one gets the machine first. This problem is esp. apparent on the slowest iOS builders.

[gopherbot]

CL https://golang.org/cl/10921 mentions this issue.