libfetchers: avoid re-copying substituted inputs

[getchoo]

Motivation

Previously, Nix would not create a cache entry for substituted/cached
inputs

This led to severe slowdowns in some scenarios where a large input (like
Nixpkgs) had already been unpacked to the store but didn't exist in a
users cache, as described in #11228

In my testing (on WSL) the speedup can be pretty drastic. As an example, here's
running nix eval in this repo after already ensuring inputs are in the store
with nix flake prefetch-inputs

Before:

$ nix --version
nix (Nix) 2.32.0pre20250921_f66b56a
$ hyperfine -N -p "rm -rf $HOME/.cache/nix" 'nix eval'
Benchmark 1: nix eval
  Time (mean ± σ):     21.665 s ±  3.579 s    [User: 3.417 s, System: 5.434 s]
  Range (min … max):   18.952 s … 29.814 s    10 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

After:

$ hyperfine -N -p "rm -rf $HOME/.cache/nix" "$PWD/outputs/out/bin/nix eval"
Benchmark 1: /home/seth/repos/nix/outputs/out/bin/nix eval
  Time (mean ± σ):      1.940 s ±  0.058 s    [User: 1.163 s, System: 0.498 s]
  Range (min … max):    1.868 s …  2.014 s    10 runs

This is a ~91% increase in performance!

Speaking of nix flake prefetch-inputs, it seems this bug also affected it, and paths would be re-copied on any uncached invocation. In practice on my machine, this made a run of take 45.5s with this repo's flake (after running rm -rf ~/.cache/nix) even though all inputs were already in the store. With this PR, it now takes about 300ms (...and I assume this is just evaluating the flake itself)

Context

Hopefully fixes #11228

This is basically the fix introduced in #12911, but adopted in a different, similarly affected code path

I'm not exactly sure if this the best solution to do that...but from what I
understand, I think it should be safe to keep the original Input information
and pair it with an accessor with a fingerprint of a technically different
input. After all, they should have the same contents given the same hash, and
attributes like lastModified go unaffected as they aren't stored in the
accessor anyways

---

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[edolstra]

This doesn't seem right to me, since it leads to an input returning a different fingerprint depending on whether it's in the Nix store or not.

[getchoo]

Took a different approach by just copying the fix from #12911 directly here instead of trying to re-use the whole code path. Seems to have the same effect!

[getchoo]

Added a release note as well, since it seems this bug has a bit of a following 😄

[xokdvium]

This will be better fixed by #14050, right?

[Mic92]

I actually don't know. @edolstra ?

[getchoo]

While #14050 is an obvious improvement to fetchToStore() caching generally, AFAICT it doesn't fix this specific issue (tested by merging it into 0175f7e and running nix eval on this repo again, same as above)

This sorta makes sense? As it only touches the unsubstituted code path there, plus the explicit caching originally introduced in #12911 remains

Now I don't really know much about libfetchers yet (or how Nix works generally...), so take this with a grain of salt: I'm pretty sure this patch is still necessary since the accessor we're constructing here hasn't undergone any previous fingerprinting or received an entry to the cache. This ends up similar to what the regular getAccessor methods for each InputScheme does, which is ensure the content exists in the store -> fingerprint it -> create an entry in the cache for that fingerprint. The unsubstituted code path handles this by simply calling to those getAccessor methods which handle all the caching for us, but since here we're grabbing an accessor from the store directly, we need to implement that same caching logic (similar to how we already implement the second step of fingerprinting)

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-2-32-0-released/70528/1