Don't hold the configuration lock during downloads

[IanButterworth]

Closes #435
Closes #561
Closes #1524

Existing draft PRs
Closes #1238
Closes #1317
Closes #746

Claude:

---

Shrink the region covered by the global juliaup configuration lock so the network download/extract of a version no longer happens while the exclusive lock is held. The same pattern is now applied to every command that downloads:

• add — splits the old install_version into download_version_to_temp (lock-free, network-bound) and commit_version_install (lock-held, fast rename + config write).
• self update — reads the configured channel under a brief shared lock, releases it, downloads juliaup with no lock held, then re-acquires the exclusive lock only to record the timestamp.
• update — two-phase: snapshot the config under a shared lock, download all needed channels lock-free (prepare_channel_update), then take the exclusive lock once to commit them all (commit_channel_update).
• update_version_db already followed this pattern.

In every case the commit phase re-checks the config (optimistic concurrency), so two processes acting on the same version/channel resolve cleanly (the loser discards its temp dir) rather than erroring.

Also:

• The "configuration is locked by another process, waiting for it to unlock" message now only prints if the lock can't be acquired within a 1s grace period, suppressing spurious messages during the millisecond-scale commit phase.
• Adds https://github.com/JuliaLang/juliaup/blob/ib%2Freduce_lock/devdocs/locking_and_update_flows.md documenting the lock model and per-command flows with diagrams.

Together these eliminate the long-lock-across-network pathology in the launcher's background daemon path (it spawns self update / versiondb update), which was the cause of the spurious lock stalls in #1524.

How this honors the discussion (#435, #561):

• Implements davidanthoff's proposed design from Unlock configuration file during download #435: read config + release lock, download, then re-acquire and commit, instead of holding the write lock for the whole download.
• Honors LilithHafner's refinement: the commit phase re-checks whether the install is still needed.
• Keeps StefanKarpinski's shared/exclusive model: many readers coexist and only block for the millisecond-scale commit, not for a multi-minute download.

Benefit over the other open PRs:

• vs Replace file locking with atomic file operations #1238 (remove file locking entirely): juliaup performs multi-file operations (install dir + config + symlinks) that a single-file atomic rename cannot keep consistent. This retains the lock for cross-file consistency while still eliminating the long-lock pathology Replace file locking with atomic file operations #1238 targets.
• vs Close config files right after read #1317 (close config files right after read): complementary — that PR shortens how long handles stay open; this shortens how long the exclusive lock is held during the download.

[davidanthoff]

It all looks great to me!

I did not try to run it yet, but maybe we merge and push out something on the dev channel and see how it goes?

[IanButterworth]

Great. I think we should get #1525 in and test this branch on it before merge.

[topolarity]

Nice work on this @IanButterworth , it seems well thought-out

It does seem to leave get_read_lock() requesting read-write permissions on the lockfile which is an issue when, e.g., using juliaup inside a read-only filesystem such as Claude's sandbox.

Do you think there's a chance to tighten those permissions so that read-only filesystems work?

[davidanthoff]

@topolarity see #1532.

[hraftery]

I guess the documentation URL should be:

https://github.com/JuliaLang/juliaup/blob/main/devdocs/locking_and_update_flows.md

Perhaps not primarily targeted at human eyes though.

[IanButterworth]

Those are dev docs not user docs.