Add Module System error contexts for imports and module argument infinite recursions

[roberth]

Apologies for the combined PR. They intersect at checkConfigNotError. Can split if desired nonetheless.

This adds two new error contexts, and a little addition to the test runner.

Loading imports of module

       … while loading imports of module `/home/user/nixpkgs/lib/tests/modules/import-configuration.nix`

• only for the latest ok-ish module, not the whole chain
• see commit message

Infinite recursion through module argument

       … while calling 'config''
         at /home/user/h/nixpkgs/lib/modules.nix:509:9:
          508|       config' =
          509|         name:
             |         ^
          510|           builtins.addErrorContext

       … *risky* while evaluating the module fixpoint, `config`

       Note that the module structure and `imports` fundamentally can not depend on the module fixpoint!
       An argument `someUnknownArg` was not provided externally through .specialArgs., so we try to load it from the module fixpoint...
       If the following message is "infinite recursion", this was the cause, and possible solutions include:
       - Perhaps someUnknownArg was misspelled.
       - Make sure that the module was loaded into the right context.
       - Provide the argument externally through `specialArgs`.
       - Structure the module such that the top level attribute set and special attributes like `config`, `imports` and `config._module.args` do not refer to `someUnknownArg`.
         (Except perhaps in a deeper structure, like a more deeply nested attribute, or a `mkIf` condition.)

       The above explanation is new. If it is inaccurate or out of place, please report a minimal example in a Nixpkgs issue and ping the Module System maintainers.


       error: infinite recursion encountered

for an example like

let
  b =
    { someUnknownArg, ... }: {
      imports = [ someUnknownArg ];
    };
in
{
  _file = "a";
  imports = [ b ];
}

This has to be the fanciest error message. I am pretty confident about this error message, but I don't have proof, hence the question to report back, which self-destructs in about a year.

Everyone with an up to date Nix will see these traces, even without --show-trace.

Dump traces

DUMP_TRACES=1 now lets us see all error traces in the test suite, including successful ones.

---

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/)
• 25.05 Release Notes (or backporting 24.11 and 25.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.

[roberth]

Nix would compulsively start its own trace items with while evaluating, but does very little except reduce the signal to noise ratio. We can use a different verb that actually conveys information.