Migrate LegacyPackageReferenceProject to PackageSpecFactory

[zivkan]

Bug

working towards: NuGet/Home#14160

Description

I finally had time to update and fix #6670

Copied from that PR's description:

Legacy csproj has some quirks, because of Visual Studio APIs. We read items via IVsBuildItemStorage.FindItems, where it's necessary to pass it a list of item metadata that you're interested in. Therefore, at some point we need a complete list of metadata names per item type, which I added to LegacyProjectAdapter. In order to ensure this list is complete, I wrote a test that's rather long and seems complicated, but what it does is runs PackageSpecFactory.GetPackageSpec on a fake project adapter that ensures there's at least one item of every type (even types that we never expect in a non-SDK style project) and validates every metadata that PackageSpecFactory asks for is in the metadata names list. This way, if the metadata names dictionary is missing an item type, the test throws, or if the test didn't create at least one item of the type, the test throws, and finally if any of the item type metadata lists is missing a name, the test throws. This gives us confidence that the product code is not missing any metadata names.

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. N/A

[nkolev92]

Small comment, that's a bit opinionated, but curious what you think.

Lots of code, especially test code, so hopefully I looked at all the importance things.
lmk if there's something in particular that needs a more detailed look.

[nkolev92]

you have a bad rebase @zivkan ping when you've fixed it.

[kartheekp-ms]

In line no: 687 we added a null check and returned string.Empty if the version is null. Should we do the same here also?

Suggested change

	string? versionRanges = projectItemInstance.GetMetadata("Version");
	string? versionRanges = projectItemInstance.GetMetadata("Version") ?? string.Empty;

[zivkan]

On line 687, the value is passed to PrunePackageReference.Create, which does not allow null, no using the string.Empty as a default is required to make the compiler happy. But I argue is a bad customer experience because it's unlikely that PrunePackageReference will work correctly with an empty value. It's just that the feature was developed because nullable was enabled on this file, so during development handling non-defined values wasn't considered (the SDK provides the values from something that auto-generates, so the risk of the version not being defined is almost zero).

This on the other hand goes through a string.IsNullOrEmpty check on the very next line and then throws, so no, I don't believe there's any benefit to defaulting to the empty string.

[nkolev92]

the SDK provides the values from something that auto-generates, so the risk of the version not being defined is almost zero.

Pretty sure PrunePackageReference would throw if a bad version is passed,

NuGet.Client/src/NuGet.Core/NuGet.LibraryModel/PrunePackageReference.cs

Lines 35 to 43 in ffd4cc1

	public static PrunePackageReference Create(string name, string version)
	{
	if (string.IsNullOrEmpty(version))
	{
	throw new ArgumentException(string.Format(CultureInfo.CurrentCulture, Strings.Error_PrunePackageReferenceMissingVersion, name));
	}
	return new PrunePackageReference(name, VersionRange.Parse("(," + version + "]"));
	}

.