don't prompt for version when --version was supplied

[Muckenbatscher]

Description

When the --version flag is supplied to aspire CLI during aspire add it would previously prompt for the version anyways.
This only happened when the supplied version is not the latest version of the selected integration package.

Now the CLI will search for all existing versions of a package and if a match to the supplied version is found, it will add it to the Apphost without prompting.
If the supplied version is not found in any of the channels the CLI will still prompt for a version bt will suggest the latest version from each of the sources.

The search for nuget versions is done with the dotnet CLI using the --exact-match flag. This will make sure that all the versions that are returned are from the same package.
The search results are cached like before. For this the key was extended to include the "exactMatch" parameter.
(This means that previously cached pacakage searches cause a cache miss now, because they wil generate a different key)

Also adjust BundleNuGetPackageCache to expand the allVersions property returned from aspire-managed to find a version, even if it is not the latest version of the searched integration package.

Fixes #15396
Reverts the workaround PR #15393

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire.dev issue:
      • New issue
  • No

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 15527

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 15527"

[Muckenbatscher]

I felt responsible for a fix because the CPM test that I introduced surfaced the behaviour and caused the CLI E2E tests to fail😀

[Muckenbatscher]

Also just noticed something:
Various testclasses use a TestDotnetCliRunner. For those I had to adjust the SearchPackagesAsyncCallback to take the new parameter exactMatch.
It seems like in the process of doing so I introduced unrelated changes from automatically applying Code Cleanup on Save in Visual Studio. This mostly includes applying the .editorconfig for whitespaces and sorting usings from what I can tell.

Would you prefer for me to alter the affecting commit to not include these changes?
So the actual changes are not polluted?

[adamint]

Would you prefer for me to alter the affecting commit to not include these changes? So the actual changes are not polluted?

Yes please!

[Muckenbatscher]

Yes please!

I've rebased the affected commits that had these changes in them.
Now the changes in the PR only include the ones relevant to fixing the --version flag for interactive package version selection.

[Muckenbatscher]

@adamint is any further action required from my side?

[adamint]

@adamint is any further action required from my side?

No, I will review Monday

[github-actions]

Re-running the failed jobs in the CI workflow for this pull request because 1 job was identified as retry-safe transient failures in the CI run attempt.
GitHub was asked to rerun all failed jobs for that attempt, and the rerun is being tracked in the rerun attempt.
The job links below point to the failed attempt jobs that matched the retry-safe transient failure rules.

• Tests / Dashboard.Components / Dashboard.Components (windows-latest) - Failed step 'Set up job' matched the transient annotation allowlist.

[Muckenbatscher]

Is anything happening in the CI environment that would cause dotnet package search Aspire.Hosting.Redis --exact-match to only return the 13.2.0 version, instead of all previous versions found in nuget.org? (for example a special nuget.config)

I removed the explicit -version parameter from the CentralPackageManagementTests in Cli.EndToEnd.Test for now. In its place I added the --non-interactive flag to skip waiting for the intearactive selection flow.
The testcases introduced in AddCommandTests in the Cli.Tests project still cover supplying the --version parameter.

[Muckenbatscher]

I saw that when running a Bundle, a different implementation of the INuGetPackageCache was resolved at runtime. The BundleNuGetPackageCache didn't have the logic implemented yet to iterate all the versions for the selected package.
This has now been added.

The bundle mode is enabled when installing the CLI locally via the dogfooding install script, and therefore also when it is being installed like this in the CI environment.