Bug

Fixes: NuGet/Home#14309

Description

Makes dotnet package update support solutions with multiple projects.

Key points:

• Projects are processed in parallel, so the perf isn't terrible on huge solutions. Each project still handles packages serially, so that's a room for improvement, as it could theoretically be slow if a project has a huge number of packages.
• Copilot was suggesting that when upgrading specific packages (for example, dotnet package update Microsoft.Extensions.DependencyInjection), if no packages were updated, then don't return an error exit code. I remember being unsure about this when implementing the first versions of package update. But now I agree to make the command idempotent. On Linux and other UNIX's, it's typically not an error to delete a file or directory that doesn't exist, because the user was asking for an outcome, even if the outcome was true in the precondition. Similarly, asking to upgrade a package to the latest version when it's already the latest, the outcome is achieved. Asking to upgrade a package that isn't referenced by a project doesn't require the project to be modified. I think this makes it easier to script package update since you no longer need to worry about whether the package is referenced or if it's already up to date. Anyway, this could be considered a breaking change, but I feel like it's better ergonomics.
• Changed the final summary message "Updated x packages from y scanned" to report the unique package id counts, so that the same package being updated in multiple projects, or the same package being checked across multiple projects, doesn't double-count. From some technical point of view, it might make sense to double count, but I think from a human point of view, if I ask for Contoso.Utils to be upgraded, it should be 1 package scanned, 1 package updated, no matter how many projects it appears in.
• Added a bunch of tests. The PackageUpdateIO class was previously untested, and it was much easier to add tests for multiple projects and debug the failing tests, than to do manual testing and debug when it crashed or had the wrong outcomes.
  • The PackageUpdateIO tests I decided to try creating a directory for the class, and then one test file per method being tested. I think I've used this pattern before in NuGet.Client, but I like it because when there are a lot of tests for a class in a single file, the test file can get very long, and then it's hard to check if a specific scenario is already tested. I hope it's easier when each method being tested has a test class.
• Made the XPlat func test collection use a const string, rather than a duplicated string literal. This caused a one line change in a bunch of files.

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.