Tests to validate floating tags

[mthalman]

An issue was recently identified where the latest tag was not being set correctly (#2307). We should consider having tests which validate floating tags in general are set correctly as a safeguard against a misconfigured manifest file.

[lbussell]

This occurred again in #5311.

[ellahathaway]

Below, I've compiled a list of "rules" that I think the floating tags should be validated against. I compiled these based off of the rules in https://github.com/dotnet/dotnet-docker/blob/main/.github/ISSUE_TEMPLATE/releases/dotnet-release-lifecycle.md and by looking at the READMEs for each repo.

• .NET Alpha version
  • Add -preview (Alpha 10 -> 10.0-preview)
  • Latest tag stays on N-1 .NET version
• .NET Preview version
  • Add -preview
  • Latest tag stays on N-1 .NET version
• .NET RC version
  • Remove -preview (RC of 9 -> 9.0-preview becomes 9.0)
  • Latest tag stays on N-1 .NET version
• .NET GA version
  • Move latest tags to newest version (GA of 9 -> move latest from 8.0 to 9.0)
• .NET EOL version
  • No entries in the manifest
• .NET Servicing version
  • Latest tags on the latest version (Servicing of 8 and 6.0 -> latest tag on 8.0)
    • Unless there's a GA release, in which case latest tag should be on GA version
• OS version
  • If two-part version number (e.g. alpine3.19 and alpine3.20), general tag (e.g. alpine) should point to latest version (e.g. alpine tag points to alpine3.20)

Below, is an implementation for the validation that I'm considering:

• Add the test to prebuildvalidation in dotnet-docker pipeline
• Use "file of truth"
  • This file would get updated as part of the release checklist
  • This file should be updated before the floating tag validation check gets run
  • Lists current version for each .NET major version, any EOL versions, and current versions of two-part version number OSs
• Based on "file of truth", parse and validate tags in the manifest based on the rules above

[ellahathaway]

Closing in favor of #5841