Add flag set-env-var to MixEnvironment, and rename old ones

[bryanhonof]

Motivation

Closes: #11495
Closes: #10338

Context

#11490 (comment)

Ref: #11490

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]

I like that this makes the flag names more consistent, but I'm concerned about the user impact, since many users have opted in to the nix-command feature flag. Perhaps the old names could be kept?

Another issue is that the effect of --set-env-var FOO followed by --unset-env-var FOO may be unexpected. These should be either mutually inclusive, or handled in the order they occur, e.g. by using a map<string, optional<string>> to represent both setting and unsetting/keeping in a single map value. Using nullopt for both unsetting and keeping might be a little weird, so you could also do map<string, variant<bool, string>> instead.

This definitely needs new tests cases to

• test the new flag
• test the interactions.

[bryanhonof]

I have another question following yours.
What if the user does the following?

$ nix run --set-env-var FOO '' --unset-env-var FOO --set-env-var FOO '' ...

Since we're talking about storing it all in a map, the second appearance of --set-env-var FOO will just be ignored altogether, right?
I don't believe it'd be correct to add "weight" to certain flags, so they do survive something like this, maybe throw a warning to the user they've added a duplicate flag?

[bryanhonof]

I gave the tests a go, let me know what you think.

[bryanhonof]

Apparently, also fixes one more shellcheck case from #10795.