cargo should avoid releasing jobserver tokens when it's going to need a new one

When building with cargo under a GNU make jobserver, cargo races with whatever else GNU make is doing. In the case of Firefox, cargo is mostly racing with clang-c++ or g++.

Because rust build times are generally worse than C++ build times, combined with the serialized nature of some crate dependencies in Firefox, it's important for rust code to build as quickly as possible, because that's what the build ends up waiting for when there is enough parallelism. And to do that it's important for rust compilation to start as quickly as possible.

What I've observed happens in practice, is that because cargo races with the C++ compiler to get tokens, it can end up waiting for new tokens, although it was holding one just moments before for a job that just finished. And this can (and does) delay rust compilations by that time it takes to get that token.

That being said, it doesn't seem to be adding that much overhead all things considered. At least it seems to be less than the overhead of waiting for tokens at the very start of the cargo build, but there, there's really nothing that cargo can do... although I wonder if one read(50) would allow to get 50 tokens faster than 50 read(1) on the jobserver pipe... (or is it write(), I forget)

Start by tracing Cargo's GNU make jobserver integration and reproduce a parallel build where a completed job is followed by token reacquisition. The work is done when Cargo no longer releases a token when it is about to need another, without adding unnecessary jobserver overhead.