Full restore support for aliasing - make the assets file aliasing aware

[nkolev92]

Bug

Fixes: NuGet/Home#14534
Fixes: NuGet/Home#14536

Description

This PR implements the restore part of NuGet/Home#12124.
The short summary is:

• Add an assets file format (version 4) that uses the alias as the pivot. Enable that assets file by default in all of code to ensure all tests are testing that code. Switch to the version 3, if SDKAnalysisLevel is 10.0.300 or lower or we have a legacy project.
• Raise NU1018, whenever duplicate frameworks are attempted to be restored with the old resolver or an older version of the .NET SDK is used (by virtue of global.json usually when nuget.exe or msbuild.exe restore is being used). All of the duplicate framework checks have been moved into RestoreCommand out of SpecValidationUtility for simpicity. They're only done when the version of the .NET SDK doesn't support aliasing, when a legacy project, or we have a legacy algo is being used.

Some more helpers for the review:

• src/NuGet.Core/NuGet.Build.Tasks/GetReferenceNearestTargetFrameworkTask.cs - We just add the current project's TargetFramework property and use it to pivot off that if there's a conflict. MSBuild equivalent in Add extra parameter to get nearest dotnet/msbuild#12932.
• In PackageSpecExtensions, I turn on nullabilitty and add the method GetNearestTargetFramework. This is the single place that knows how to disambiguate by alias. Beyond the assets file, this is the meat and potatoes of the change. It is thoroughly tested.
• In src/NuGet.Core/NuGet.DependencyResolver.Core/Providers/IDependencyProvider.cs, which is what gets called when anyone in restore needs a project or package, we plumb the target alias and use it to disambiguate.
  • src/NuGet.Core/NuGet.Commands/RestoreCommand/SourceRepositoryDependencyProvider.cs is packages, so we don't plumb the alias.
  • src/NuGet.Core/NuGet.ProjectModel/PackageSpecReferenceDependencyProvider.cs is for the projects, so this is where the majority of the work is. This is where GetNearestTargetFramework on a PackageSpec is called.
• In src/NuGet.Core/NuGet.Commands/RestoreCommand/RequestFactory/RestoreArgs.cs, we downgrade the assets file version to v3 for legacy projects. By setting it here, we ensure it's done in proper restore, but ensuring the tests are actually using the new version.
• In src/NuGet.Core/NuGet.DependencyResolver.Core/ResolverUtility.cs, the cache key now accounts for the alias as well.

Assets file and dg spec (packagespec) read/write changes pointers:

• The PackageSpecWriter, which writes the package spec, has a legacy and "new" writer. This writer is used in 3 different places. The assets file file, the dg spec writer (dgspec.json in the obj folder) and the no-op hash. In order to avoid having to version the package spec, we only use the legacy writer in the assets file, when the version is 3. This ensures all of our tests are actually covering the new codepath and we don't accidentally break the legacy projects. The way the package spec writer is implemented probably allows the legacy projects to have v4 of the assets file, but I'd rather do that at a later point to minimize the risk of this current change.

• Every time we write the package spec now, we write a "framework", which is basically the effective framework. For simplicity, we write this every time.

• LockFileTarget.Name is what's being written as the key, so in LockFileBuilder, we set the Name based on the version. Similarly, the LockFileTarget reader, v3 and v4, will set the name based on the version. If V3, we fill out the TargetAlias, if V4, we fill out the Framework (which is not longer written).

• In LockFileFormat, the default version is 4. Whenever we use V4 of the LockFileFormat (or assets file), we use the default package spec writer, with version 3, we use the legacy writer.

• I cleaned up any global suppressions whenever I saw it fit. The fewer of these we have, the better.

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.

[zivkan]

Just finished going through the product code, but haven't started looking at the tests yet. Thought I'd share my comments so far.

[zivkan]

I always find tests hard to review. They all look so similar, making it hard to see the differences between them. I don't have any ideas how to make it better though.

[jeffkl]

Thanks for undoing the breaking changes

because

[nkolev92]

@jeffkl, @zivkan I think it's ready for a final review.