`rustc_data_structures::jobserver` should fall back to an in-process implementation if no jobserver in environment

[anp]

In #88091 we discovered a scaling limit on concurrent rustc invocations when run outside of a build system that provides a jobserver pipe. In that configuration, the compiler creates its own pipe for internal thread scheduling, which means that each invocation of rustc makes a pipe with two pages. On Linux, there is a soft limit on the number of per-user pipe pages which roughly nets out to allowing up to 512 concurrent rustcs if there were no other processes using pipes.

Per @alexcrichton in #88091 (comment), this fallback jobserver doesn't need to be inherited by any forked processes which should mean it's OK to use an in-process concurrency controller instead of the jobserver client.

Looking at the code, I think it should be possible to refactor rustc_data_structures::jobserver::client() to return a shim that can either dispatch to a real jobserver client or to an in-process semaphore. The client only seems to be used for rustc_data_structures::jobserver::{schedule_thread,release_thread} and for LLVM thread creation, so it should be a smallish refactor.

cc @tmandry

[alexcrichton]

Oh FWIW I was originally naively assuming that this would happen internally in the jobserver crate itself. There's already an in-process implementation there for platforms that don't have pipes (e.g. wasm IIRC) so that's what I expected to be reused. That being said using doing this all in rustc seems plasusible as well. In general though this probably isn't too necessary since pipe usage isn't hot in any rustc usage pattern and this hasn't otherwise ever been a problem in practice.

[anp]

That makes more sense! I imagine rustc would still need to call a different function than Client::new, right?

[alexcrichton]

Indeed yeah!