Filter framework-mismatched assemblies from NUGET_PLUGIN_PATHS

[zjrunner]

Prior to this, if you configured both a netcore and a netfx plugin to handle both nuget and dotnet,
both would fail. One would fail on the dll, the other on the exe.
nuget_plugin_paths=d:\tools\credprovider\plugins\netcore\CredentialProvider.Microsoft\CredentialProvider.Microsoft.dll;d:\tools\credprovider\plugins\netfx\CredentialProvider.Microsoft\CredentialProvider.Microsoft.exe

This change does a naive filter based on existing discovery models for convention-based plugin loading.

Bug

Fixes: NuGet/Home#8151
Regression: No

Fix

Use the same logic as the convention based plugin discovery to filter the paths in NUGET_PLUGIN_PATHS. Do not fallback to the baseline discovery if all paths are filtered out to hold a line on typo discovery. This does exclude self-contained dotnet exes from plugin_paths, but since they weren't possible in discovery anyway this feels like an ok compromise.

Testing/Validation

Tests Added: Yes
Validation:
verified failure of nuget 5.0.0 as in the linked issue, verified failing unit test as created, fixed the code, verified passing unit tests and passing commandline of built-nuget.exe

[dnfclas]

All CLA requirements met.

[nkolev92]

I just now noticed this. :)
Thanks for creating the PR @zjrunner

[nkolev92]

This does exclude self-contained dotnet exes from plugin_paths, but since they weren't possible in discovery anyway this feels like an ok compromise.

Not sure what you mean by this?

[nkolev92]

I'm ok with this change.
We need to document it.

If you define a plugin for .NET Framework, you need to define one for .NET Core as well.
The environment variables are a special scenario.

We are also kind of changing the behavior where we require plugins to be exe or dll, but I don't imagine that's a big deal, as the convention based discovery already does that.

Again, we can document that.

[nkolev92]

@rrelyea @anangaur @dtivel
Can you please review this behavior change?

[nkolev92]

@rrelyea @anangaur @dtivel

Can you please take a look at this so we can merge it to 5.2?

@zivkan @heng-liu @dominoFire @donnie-msft

Any feedback is appreciated.

[rrelyea]

dotnet3 sdk now will create an exe by default for netcoreapp3 projects. (tested with p5 on my machine)
as such, i'm concerned about the reliance on the file extension.

[nkolev92]

Another option that we discsussed would be multiple environment variables. One of netfx and netcore each.

Those variables would take preference over the old one which would apply to both.

[nkolev92]

Sorry for the delay @zjrunner
Due to the concerns with the extension approach, we will go for a 2 env var approach.
Any issues with that from your end?

I will have a write-up and a PR later today.

[nkolev92]

Closing in favor of #2986.