bootstrap: Make low priority the default - #165707

The low-priority option is tucked away so far in bootstrap.example.toml that it's nearly impossible to discover by anyone who doesn't think they're doing anything niche (see #165702). However, it is beneficial to have it enabled on nearly every system, since a build is a CPU-saturating batch job that has no business preempting foreground applications, which predominantly have nice 0. Consider the following three scenarios ensuing from the change from low-priority = "false" to low-priority = "true":

• There are no processes with non-negligible CPU usage between nice 0 and 10, and bootstrap builds do not get preempted by anything. A system on which this is the case will be unaffected by this change. Examples include CI runners and other build environments with proper build queuing.
• There are foreground processes between nice 0 and 10 that are relatively light on CPU compared to a bootstrap build and were previously being heavily preempted by bootstrap builds. With this change, a system on which this is the case will see a significant improvement to the latency of interactive programs, enabling the user to comfortably do other things while the build is running without affecting the throughput of the build itself (as the programs are, as established above, light on CPU).
• There are CPU-intensive but not CPU-saturating foreground processes (games, office and productivity software, Jupyter notebooks, etc.) between nice 0 and 10 that constantly compete with bootstrap builds for CPU time. With this change, a system on which this is the case will see CPU time allocation be biased toward the foreground CPU work at the expense of the build, which is most likely what the user wants, since they wouldn't run CPU-intensive things in the foreground if they didn't want them to have priority over background batch jobs whose completion they are passively waiting for.
• There are CPU-saturating batch jobs between nice 0 and 10 that constantly compete with bootstrap builds for CPU time, interfering with each other and performing worse than if a batch job queue was in operation and one job ran after the other. With this change, a system on which this is the case will see the bootstrap build receive less CPU time, but the overall sum of batch jobs will complete in approximately the same amount of time regardless, and may even complete sooner due to reduced competition for CPU cache and OS page cache. In any case, this is a misconfigured and a priori suboptimally performing setup, and it will not see good performance unless some form of job queuing is implemented. Admins may implement a low-priority = "false" override as a hacky stopgap if it is desirable for the bootstrap build to engage in disruptive competition for resources and win against some other batch job running in parallel.

Some may wonder why agonizing over this is necessary to begin with if this is such a clear-cut case that operating systems are supposed to deal with automatically. The answer is that the operating systems of today are still not very good at making this sort of scheduling decision in that their capacity to implement such logic automatically is limited and non-robust in unintuitive ways.

For example, the automatic prioritization of foreground programs for scheduling purposes in Windows, known as quantum boosting, can only confer priority boosts to the threads of the process that owns a foreground window, which means that if the graphical application displayed within that window has an IPC dependency on a different process (as is the case with the likes of Jupyter notebooks and even regular web browsers), that dependency will not receive the quantum boost or any other kind of priority increase.

On Linux, meanwhile, no such heuristics exist to begin with (due to graphical applications not holding any special status in the scheduler), and the only mechanism to prevent CPU-intensive and CPU-saturating batch jobs from preempting foreground applications is the emergent heuristic of completely fair scheduling, in which tasks with less total CPU time accrued will have higher priority. This is even more flawed than quantum boosting on Windows, as long-running graphical applications will easily get preempted for long periods of time by the constantly spawning rustc processes of a build that have no history of high CPU usage.

In summary: there are commonly occurring setups on which this change is beneficial, commonly occurring setups on which this change does nothing, and extremely niche and typically broken use cases where this change does something that cannot be conclusively deemed positive or negative.

Large language models were not used in the production of this PR.