Run unit tests with clean config

[roberth]

Motivation

@edolstra found an error running the tests in the dev shell.

It turns out the normal initialization still ran, and loaded configuration that caused the error.

This PR disables the loading of external configuration during unit test execution, and makes it possible for test suites for C API based bindings to do the same.

Context

The error was:

tests/unit/libutil-support/tests/nix_api_util.hh:34: Failure
Failed
nix_err_code(ctx) != NIX_OK, message: error: creating cgroup '/sys/fs/cgroup/user.slice/user-1000.slice/session-7.scope/nix-build-pid-2087076-2': Permission denied
tests/unit/libexpr/nix_api_expr.cc:162: Failure

This error was only recently possible, as #10412 was the first PR to run small builds as part of the unit tests.
Building in unit tests should perhaps be kept to a minimum, but I have to note:

• single derivations are pretty fast to build
• we need to be able to build in various environment for the functional tests anyway
• this was the only way to test that part of the C API
• mocking only works if you have exceptionally good interfaces and the mocking code is reviewed over and over, if it works at all

Priorities and Process

Add 👍 to pull requests you find important.

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

[roberth]

Unchanged code from here down.

[roberth]

The libstore test suite ironically did not exhibit the problem, because it was the C API tests that triggered the problem, which are mostly libexpr focused. (nix_string_realise)

Unit tests that exercise build code should be possible to add though, so I've applied the same solution here.

[edolstra]

Wouldn't it be easier to do what we do in tests/functional/common/vars-and-functions.sh, i.e. set $HOME etc. to known values? That way it wouldn't need any code changes.

[roberth]

I think it's cleaner to not even look in those places.

Ideally we wouldn't even have such globals, and then we can trivially clean up the new code I wrote here.

[roberth]

Doing it in C++ also helps with portability.

[Ericson2314]

There are global variables in libutil I am afraid too (the experimental feature settings).

Would it be possible do this less imperatively in the C++, e.g. adding arguments to the C++ init functions? (OK if the C interface is still stateful since compat is more of an issue there.)

[roberth]

Good call. A new flag is a much simpler solution, and we don't need a particularly extension pattern at this time (or ever, hopefully).
On the C side, where we don't have overloading, it's just a new function.

[roberth]

Part of why the diff is smaller now is that I'll do separately the part where libstore tests become capable of building.
That's not needed yet, but good prep nonetheless for the build improvements that may be coming, so I'll do that in a followup.

[Ericson2314]

Still needed?

[roberth]

It wasn't!

[Ericson2314]

Except for my little note