Generate solution-level nuget.config with cleared Package Sources sections

[donnie-msft]

NuGet Product(s) Affected

Visual Studio Package Management UI, dotnet.exe

Current Behavior

When using NuGet Tooling to add a NuGet setting, NuGet.Configuration.dll will walk up the tree of nuget.config files until it finds a matching section. Even if a solution-level config file exists, it will not write Package Sources sections to it.

If a solution-level config exists with <packageSources> and the customer disables one of those sources using Visual Studio Options, the <disabledPackageSources> node will be created in the machine-wide config.
However, if <disabledPackageSources><clear/></disabledPackageSources> exists in the solution-wide config then that section will be updated as expected.

https://learn.microsoft.com/en-us/nuget/reference/nuget-config-file#package-source-sections

Desired Behavior

Since customers are encouraged to follow this suggested best-practice anyway, I believe tooling should guide them by generating a solution nuget.config implementing those practices, unless the customer expresses otherwise.

To steer customers towards solution-level configs, the following workflow is suggested for NuGet Tooling (eg, VS Options or dotnet new nugetconfig) when that tooling attempts to write to a Package Sources sections.

VS Options

When modifying any of the package sources sections, check the package source sections using the following workflow.

1. Solution config exists? If not, create one.
2. The node being modified exists (in solution config)? If not, create one with <clear/>.
3. The node being modified exists (in solution config) but is missing a clear? Add a <clear/>.
4. Repeat 2-3 for all package sources sections.
5. Write the actual change to the section.

Prompt the customer if steps 1-4 find a missing ideal configuration. If the customer agrees, NuGet tooling completes steps 1-3 in the solution config for the customer.

Otherwise, continue to step 5.

dotnet new nugetconfig

Customers using the nuget.config template without parameters will continue getting only the <packageSource> node from the package sources sections by default. Provide CLI options for appending the remaining package sources sections.

Primarily, these options should be available:
--add-package-source-mapping
--add-disabled-sources

Secondarily, these options could be available:
--add-package-source-credentials
--add-api-keys
--add-active-package-source
--add-trusted-signers

Potentially useful as well may be --no-clear in case customers intend to create a merged configuration.

Additional Context

Feature suggestion of a dotnet CLI config command: #9571
Suggestion to stop creating default configs and/or prompt customers to use the dotnet new nugetconfig: #13027