treewide: support NIX_SSL_CERT_FILE as an impureEnvVar

[timbertson]

(this is a reopened version of #271161 for technical reasons)

Description of changes

tl;dr this PR makes NIX_SSL_CERT_FILE the preferred way to control CA certificates throughout nix, by allowing it to be set as in impureEnvVar, including it in proxyImpureEnvVars, and ensuring fetchers support it.

---

Nix (the executable) as well as much of its packaged software respects NIX_SSL_CERT_FILE as the preferred way to specify a custom set of root certificates. Within derivations, this is typically done by the setup hook of cacert.

However, there's no way to inject this variable from outside (with impure env vars used in fetchers). This is required for most use cases of an an https proxy, as the proxy's own certificate will not likely be trusted by nix's builtin cacert package.

Functionality for injecting a custom trust store has been added to fetchgit, but because the setuphook will always override NIX_SSL_CERT_FILE, a different envvar had to be used (NIX_GIT_SSL_CAINFO). I have an open PR to add this same customisation to the go module fetcher.

However, it'd be preferable if we didn't invent a new envvar, and instead made NIX_SSL_CERT_FILE the single way to control this setting for both fetchers and nix itself.

For this to work, we need two small changes:

• cacert should only set this variable if it's not already set, so that any impure version is not overwritten
  • this is in a setuphook so it's a mass rebuild
• add "NIX_SSL_CERT_FILE" to proxyImpureEnvVars (fetcher.nix). It's not strictly a proxy-only variable, but:
  • this needs to be overridden for all HTTPS proxy use cases, and most things are https these days. Currently fetcher support for custom certs is patchy, because they're all doing their own thing (see below notes)
  • using the certificates the system has explicitly set for nix (if any) is inline with user expectations even outside proxy setups, and this only affects fixed-output derivations anyway

Various fetchers current (and updated) behaviour is oulined below:

• fetchgit: previously added explicit support for NIX_GIT_SSL_CAINFO as the impure overrideable version. This is still supported, but the standard NIX_SSL_CERT_FILE now works and is preferred.
• fetchurl: passes --insecure to curl for a fixed-output derivation, so I guess it doesn't need modification
• fetchgomodule: previously no support for custom certs for git dependencies, now sets GIT_SSL_CAINFO to the value of NIX_SSL_CERT_FILE using whatever's provided by the user / setup hook

Looking through other fetchers, it seems most of them either have their own schemes or delegate to fetchurl. So this isn't a wide-reaching code change, but I think it's important to support NIX_SSL_CERT_FILE as an impureEnvVar, so that we don't force fetchers to invent their own envvars for this purpose.

Things done

Since this is a mass-rebuild, I tested locally by only applying these changes to the version of cacert used by fetchers. With these modifications I tested fetching over https (using custom certs) with:

• fetchurl
• fetchgit (over https)
• go modules fetch (git https)

• 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.05 Release Notes (or backporting 23.05 and 23.11 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.

[timbertson]

@roberth would you mind taking another look at this now that I've rebased?
(I had to close the old PR which you commented on previously, #271161 (comment))