Discover plugins installed using Net tools

[Nigusu-Allehu]

Bug

Fixes: NuGet/Home#13740

Description

This PR makes sure NuGet discovers credential providers installed using .NET tools.
dotnet tool install <provider package name> --global should install the tool and add its path to the PATH environmental varibale. Iterate through all the paths in PATH and all the files in the path to find the plugins. By design, we expect these plugins to be named nuget-plugin*.

This PR introduces a new TFM, net8.0, to NuGet.Protocol. The primary reason for adding net8.0 support is to take advantage of newer APIs, specifically File.GetUnixFileMode(fileInfo.FullName), which simplifies handling file permissions in Unix-based systems.

Plugin discovery method

The discovery is done based on which environmental variable has been specified

• If NUGET_NETFX_PLUGIN_PATHS or NUGET_NETCORE_PLUGIN_PATHS have been specified, use the old discovery method to look up non dotnet tools plugins in the paths added in the env variable.
• If NUGET_NETFX_PLUGIN_PATHS and NUGET_NETCORE_PLUGIN_PATHS have not been specified
  • if NUGET_PLUGIN_PATHS specified,
    • Collect the set of plugins the env variable is pointing to: They could be donet tools or non dotnet tools plugin files.
  • if NUGET_PLUGIN_PATHS not specified,
    • Discover all plugins using the default discovery method

Default discovery method

• For dotnet tools
  • Traverse all the directories specified in PATH env variable, and search for executable nuget-plugin-*files
• For non dotnet tools
  • %UserProfile%/.nuget/plugins

PR Checklist

• Meaningful title, helpful description and a linked NuGet/Home issue
• Added tests
• Link to an issue or pull request to update docs if this PR changes settings, environment variables, new feature, etc. Document .net tools Plugin feature Home#13858

[Nigusu-Allehu]

Test priority of the discovery methods we have. This test makes sure we prioritize the environmental variables.

[kartheekp-ms]

Great progress. Left few comments on the new changes proposed.

[jgonz120]

This looks fine to me. There were a couple of instances where you're checking for null results from private/internal methods which don't return null.

[kartheekp-ms]

nit: There is an opportunity to refactor here because we set/remove execute permissions for files in all the new tests. I think we can create a private utility method and invoke it from the tests as needed. Please feel free to address it a follow-up issue.

[kartheekp-ms]

Given that Process.WaitForExit waits indefinitely for the process to exit, while addressing this comment you might want to consider this code by changing it to the following:

Assert.True(process.WaitForExit(1000), userMessage: "some string that helps to troubleshoot the issue");

With this approach, the test fails gracefully if the process doesn't complete on time for any unknown reason.