Support for new Workload Set Versions

[marcpopMSFT]

New list based on today's conversation that needs to be merged into the list further below:

• publish workload sets from the workload set repo
• figure out branching
• dotnet workload update --workload-state global state saved into programdata on whether to use workload sets or not
• dotnet workload install, restore, update should work with the state
  • file based install
  • admin based install
• how does rollback work if workload-state is on set (should override)
• explore how we store the workload install state (set versus not) in workload history
• Refactor workload set and workload install/update logic #39991
• Use version comparison function #41102
• Add test #40548
• Workload set garbage collection
• Userlocal workload installation/updates are broken in 8.0.300 #41420
• Document workload sets and new switches
• Review the process for disabling workload sets or changing out of it
• [ ] Baseline workload set in installer
• Workload sets in VS #41607
  • Workload set drop creation
  • workload set insertion
  • Do we want to create drops/insertions for workloads themselves
  • figure out automated codeflow
  • figure out auomated publishing (publish to VS eventually?)
• Confusing error for missing workload set requested in global.json #40297
• Change default workload set use to 'true' #45936
• Figure out the process of publishing the workload sets to nuget.org

This is the initial work in arcade and the resolver to support workload sets
dotnet/designs#294

Arcade

• Support for workload set versions - authoring workload set assets and packages #34282

Workload resolver (overlap with workload set version)

• sync on serialization effort within global.json code
• Error if trying to pin to a baseline workload set version (as those packs likely aren't available)
• TBD do we resolve the latest manifests available or the latest with packs installed
• Add flag for --workload-state when installing/update workloads for the old install behavior #34561
• Add flag to stop using the workload set version and just use the installed manifests #34562
• ensure that resolver can get out of workload sets (i.e. detect Workload Install State and use that to determine loose manifests vs Workload Sets)
  • potential workaround: use a rollback file explicitly and specify that

Workload CLI

• enable support for workload set versions for --info/list - Add dotnet workload --version command, display workload version other "info" commands #33912
• Workload updates with workload sets
  • Update TempDirectoryWorkloadManifestProvider if needed
• Figure out what to do with baseline manifests and workload set versions during garbage collection
• Support for specifying a workload set version during install/uninstall commands
• baseline workload set version in installer
• file based install of workload set version
• Enable support for workload set versions for repair
• enable support for workload set versions for history
• enable support for workload set versions for clean
• Write workload set GC root when running restore, update, or install in folder with global.json
• Use workload set GC roots for garbage collection
• [Workload Sets] ensure that users can get a full listing of all installed workloads (including multiple versions) #37828

Workloads set repo

• New repo with list of workloads in a .props file #34031
• Check compliance for the new repo (SBOM creation)
• Onboard to arcade changes above to produce the package
• Figure out branching structure (presumably by feature band but what about previews)
• Enable darc codeflow from runtime
• enable darc codeflow from maui
• enable insertion pipeline flow into VS for workload set
• investigate whether we need an internal version of the branches/repo

Miscellaneous

• Engage Tizen on the planned changes to workloads and how it will work for their workload
• Fix GC to clean up empty manifest folders Add workload garbage collection tests for side-by-side manifests #35857 (comment)