feat(dist): stage fresh toolchains before atomic publication

[cachebag]

This PR implements the second step of the plan discussed in #4663 (details in my design notes), addressing #4400 and #4724 for fresh installs.

The idea is that a fresh toolchain now builds in its own "staging" directory and is then published to toolchains/<name> with a same-filesystem rename, with the update hash only being written after publication. In the case of an interrupted install, this means no partial toolchain is left behind and a retry always works. The stage itself lives at a deterministic per-toolchain path guarded by an OS-released file lock, so an abandoned stage gets reclaimed by the next install instead of accumulating, and a concurrent install of the same toolchain fails fast instead of racing.

Updates still modify toolchains in place, and blocking instead of failing is deferred to the locking work in #988.

cc @rami3l

[rami3l]

Thanks!

I have a question though: If I understand it correctly, we are performing the final stage of the installation in an isolated path under toolchain/ in this case (so no indirection WRT the actual toolchain), how can this evolve into the A/B partitioning scheme as we have previously discussed?

View changes since this review

[cachebag]

If I understand it correctly, we are performing the final stage of the installation in an isolated path under toolchain/ in this case (so no indirection WRT the actual toolchain), how can this evolve into the A/B partitioning scheme as we have previously discussed?

@rami3l
For a fresh install there is no "A" side to keep alive, so atomically renaming the finished directory to toolchains/<name> is observably the same as flipping a reference there: you go from nothing to a complete toolchain in one step. This is the special case you pointed out in #4724.

IMO, this PR builds the half of A/B that will be invariable for us in the near future: the complete "B" side is constructed in an isolated stage, alias-scoped metadata isn't touched until the commit point, there is exactly one atomic publication operation, and the stage is owned through a crash-released lock so an abandoned B side gets reclaimed. The only thing that changes when we introduce real A/B is the body of StagedToolchain::publish(): instead of rename(stage -> toolchains/<name>) it becomes rename(stage -> heap/<object>) followed by an atomic reference flip at toolchains/<name>.

Does that make sense?

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.