Adding accepted SDK name match pattern to SDK manifests.

[AR-May]

Fixes #7293

Context

Previously all SDK resolvers were loaded and then ordered by priority. The resolvers are tried one after one until one of them succeeds. In order to decrease the number of assemblies to be load we change the behavior since ChangeWave 17.4. Now the resolvers might specify the name pattern for sdks they intend to resolve. If sdk name does not match, we would not unnecessary load the resolver.

Changes Made

• The manifest file now could have NamePattern of the resolvers specified. The change is backward but not forward compatible.
• The resolving algorithm works in two passes. On the first pass all the specific resolvers that match the given sdk name would be loaded (if needed), ordered by priority and tried one after one. If the sdk is not found, on the second pass all general resolvers would be loaded (if needed), ordered by priority and tried one after one. This change is under the ChangeWave 17.4.

This change of algorithm might lead to a change in sdk resolution in the following situation:

• we have two resolvers A and B, priority of A is higher than priority of B, but A is general and B is specific.
• the sdk of the project might be resolved by two resolvers, A and B.

Then before the change the project is resolved by resolver A and after with resolver B.

Testing

• Old & new unit tests
• Manual tests.
• DDRITs

[rainersigwald]

Overall looking very nice. This is mostly style/perf nits.

[Forgind]

This doesn't feel like an internal error to me.

[rainersigwald]

I was also torn but the only real alternative is InvalidProjectFileException and since this is a problem with the SDK resolver I think InternalError is a better choice.

[Forgind]

I agree Internal > InvalidProjectFile, but why are those the only options? Internal makes it sound like it's a bug in MSBuild. It might be a bug in one of our SDK resolvers, but it might not be, and in fact, since we've tested ours, it presumably isn't. It's a fix-your-own-build problem.

[AR-May]

Well, it is not fix-your-own-build, rather fix-your-own-msbuild-cause-you-broke-it. I do not know a way to do that out of the project files. There is an option to specify additional folder for sdk resolvers and where customer's resolvers could be in theory located, but it is my understanding that it is a non-documented env variables.

[rainersigwald]

I was also torn but the only real alternative is InvalidProjectFileException and since this is a problem with the SDK resolver I think InternalError is a better choice.

[benvillalobos]

First pass, everything's looking good 👍

Going to give it another pass, but don't block on it if things move smoothly.