Parallelize proc macro expansion

[Shourya742]

This PR replaces the single proc-macro server per workspace with a small pool of server processes.

[Veykril]

Let's make this configurable, similar to how cachePriming_numThreads is configurable (just for processes instead of threads), so

#[derive(Serialize, Deserialize, Debug, Clone, PartialEq)]
#[serde(rename_all = "snake_case")]
- pub enum NumThreads {
+ pub enum NumProcesses {
    Physical,
-    Logical,
    #[serde(untagged)]
    Concrete(usize),
}

[Veykril]

and let's make the default Concrete(1) for now so we can have people test this as an opt-in for a bit

[Shourya742]

I implemented this, with one caveat: in a few CLI commands we don’t instantiate Config. In those cases I didn’t instantiate config through just to fetch the process count and instead defaulted to 1.

[ChayimFriedman2]

This PR is based on requesting expansion from the least overloaded worker. I wonder, now that the protocol is bidirectional, can we instead make the proc macro server request "more work" from r-a? This will more evenly parallelize in case some expansion takes a long time.

[Shourya742]

This PR is based on requesting expansion from the least overloaded worker. I wonder, now that the protocol is bidirectional, can we instead make the proc macro server request "more work" from r-a? This will more evenly parallelize in case some expansion takes a long time.

While working on the current pool design, I also considered a client-side approach closer to work stealing or availability-based scheduling. In this model, the client would wait until any worker becomes free and then dispatch the next request. This keeps scheduling centralized and fits naturally with the existing pool setup. I can add this in a follow-up.

If we instead move scheduling to the server side, things get more involved. The client would need a dedicated listener thread to receive subrequest/request signals from the servers and dispatch work accordingly, along with a way to track request completion. One nice property of this approach is that it pushes the architecture toward a more asyncy type model, the client could fire-and-forget requests and later query the listener thread when it actually needs the result.

[Veykril]

Do you mean the client should batch up multiple expansion requests? That makes things fairly complicated again, just like multiplexing the connection to allow multiple inflight expansions (due to proc-macros observing the process environment). I think parallelization should for now be done via multiple processes as that can live separately from the protocol and is easy enough to implement.