Re-enable env var directives in the .NET CLI

[baronfel]

Fixes #37686

Description

This re-adds the EnvironmentVariableDirective, which used to be a default part of the CLI configuration but was removed in a refactoring.

Customer Impact

Customers that set environment variables using this mechanism (which is OS agnostic and scoped only to a single command) suddenly had their commands break. After this change, their scripts will work again.

Regression?

Yes, a System.CommandLine update broke silently in the 8.0.100 preview cycles.

Risk

Low

Tests

Automated tests were added to ensure the env-var setting functionality is verified at the SDK-level, not just the S.CL-level.

[baronfel]

We'll need to get servicing approval for this one

[baronfel]

Approved for servicing over email, merging!

[MiYanni]

@baronfel I dug a little in the history and it doesn't look like this was "forgotten" per se. What seems to have happened is the structure of how it was indicated in the S.CL changed in a major breaking change in the June timeframe. In the past, it is likely this functionality was included in some other directive, as I don't see it explicitly being enabled in our code from this pull request. But now, they've made it its own explicit directive and that wasn't added because, since we didn't have tests for it, it didn't seem to be needed/required. So, a series of changes/oversights lead to the functionality not being included. 🙃 Thank you for adding the test as that will help the functionality remain, even if S.CL changes more under the hood.

[xt0rted]

@MiYanni back when I started testing out System.CommandLine I looked through the code numerous times trying to figure out how this was wired up since there were no explicit calls to .UseEnvironmentVariableDirective() or .UseDefaults(). I could never find anything but my theory is it was an accidental side-effect of how commands are sometimes invoked. In this project command.InvokeAsync(...) is called from a number of locations, and depending on how that is called you can get sent down a path that ends up calling .UseDefaults() which includes .UseEnvironmentVariableDirective().

• These https://github.com/dotnet/command-line-api/blob/3e0db9e5830f2722645b9a576f80e3650b50f23a/src/System.CommandLine/CommandExtensions.cs#L28-L57
• Call this https://github.com/dotnet/command-line-api/blob/3e0db9e5830f2722645b9a576f80e3650b50f23a/src/System.CommandLine/CommandExtensions.cs#L76
• Which can then call this https://github.com/dotnet/command-line-api/blob/3e0db9e5830f2722645b9a576f80e3650b50f23a/src/System.CommandLine/SymbolExtensions.cs#L56

[MiYanni]

@xt0rted Ohhhh! Okay, that's good to know. I didn't know it was .UseDefaults() that was triggering this to happen previously. Any refactoring efforts can have some things fall through the cracks. But adding more tests like what was done here helps those things get caught before they go out the door. 😄