make(Binary)Wrapper: record created wrappers

[abathur]

Description of changes

Write a machine-readable list of wrappers (each line is a $wrapper:$original pair) to ${output-wrapper-is-being-written-to}/nix-support/wrappers.

A wrapper -> original mapping makes it easier to see through wrappers, especially binary wrappers, to the original executable.

One case where this helps is when you need to perform analysis on the actual executables and associate that analysis with exec wrappers.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[abathur]

I'm not certain whether this writes into the "right" output.

Before I started trying to figure out how to support multiple outputs here, the first draft of this wrote these into ${!outputBin}.

For a bit, I had myself convinced that automatic and manual moveToOutput behavior would break some of the linkages here (leaving the record in the wrong output and pointing at a stale path) unless we could either figure out how to write the record into the correct output from the start, or perhaps relocate them during fixup.

Now I'm starting to think it may be okay not to sweat this much, since wrappers should also get broken by moveToOutput (probably leading packages that need both to create wrappers directly in the correct output in postFixup or later). Based on that assumption, I've force-pushed to update this to try to just discover the store path prefix that the wrapper is being written to, and record the wrapper within that output.

(The risk of multi-output handling breaking this linkage is technically still here, but any package with this problem likely already has broken wrappers and I suspect that fixing the wrapper will generally fix the record?)