workload repair can recover from corrupt workload sets

[nagilson]

context

for #52090
copilot failed attempt #52338

Issue: The Workload Manifest Reader can fail with ManifestFromWorkloadSetNotFound when calling GetManifests when package managers clean up manifests from older sdk versions that were still needed by the newer version workloads.

❗ This PR is better reviewed with hiding whitespace changes.

Manual Testing Loop Demo

./artifacts/bin/redist/Debug/dotnet/dotnet exec ./artifacts/bin/redist/Debug/dotnet/sdk/10.0.103-dev/dotnet.dll --debug workload install macos
rm -rf  /workspaces/sdk2/sdk/artifacts/bin/redist/Debug/dotnet/sdk-manifests/10.0.100/microsoft.net.workload.emscripten.current/10.0.102/

./artifacts/bin/redist/Debug/dotnet/dotnet exec ./artifacts/bin/redist/Debug/dotnet/sdk/10.0.103-dev/dotnet.dll --debug workload --info

./artifacts/bin/redist/Debug/dotnet/dotnet exec ./artifacts/bin/redist/Debug/dotnet/sdk/10.0.103-dev/dotnet.dll --debug workload repair

What's this do

I considered removing the workload set entirely during workload manifest search if the manifests didn't exist and it was corrupt but this would prevent the repair from working and still require user interaction.

Removing the error is not sufficient because then we never recover from the bad state or detect the bad state.

So, now we have a separate class which tries to repair missing manifests before we start the manifest lookup. The errors for missing manifests are disabled in the recorder because the recorder will fail to initialize if the manifests are corrupted and it doesn't have the data available to repair or recover from that state. We do the sub-manifest repair because the manifests need to be in a good state for the rest of repair to have the correct data to function. The repairer being hooked into the Installer means commands such as repair will get the hook to do so, but commands such as --info never initialize an installer through the factory, so they instead print a prettier error.

Notes

I tested and confirmed:
repair, restore, update are fixed.
--info, workload --info, workload list show the small error.

[nagilson]

There's some polish needed if this isnt urgent:

1. The error string should likely contain the workload id and not just the version
2. We should try to dedupe the message if possible, despite separate assemblies
3. The MissingManifests logic is also implemented in two approaches, which has potential for consolidation
4. It may not be required to attach in the factory method and we should reconsider if we can do that at the IInstaller level
5. The sdkFeatureBand parameter is unnecessary in the CorruptionRepairer

[nagilson]

The test failure seems to be due to a change in the new, more specific error message presenting in some cases instead of an existing error message.

[marcpopMSFT]

I tested in codespaces. I can confirm that if I delete any workload manifest (after installing), I will get errors during --info, workload --info, and build. I can also confirm that repair, restore, and update all fix the problem.

The error experiences themselves could probably be cleaned up a bit as they give full exception stacks in 2/3 of those flows (workload --info is the best Ux). But this is sufficient for unblocking the customer. Need to fix the tests and review.

[nagilson]

/xlf

[github-actions]

▶️ XLF update workflow started. Track progress in this workflow run.

[nagilson]

There's some polish needed if this isnt urgent:

1. The error string should likely contain the workload id and not just the version
2. We should try to dedupe the message if possible, despite separate assemblies
3. The MissingManifests logic is also implemented in two approaches, which has potential for consolidation
4. It may not be required to attach in the factory method and we should reconsider if we can do that at the IInstaller level
5. The sdkFeatureBand parameter is unnecessary in the CorruptionRepairer

1. there is no id, just the set version. I've improved the err message
2. not easily done as it'd make a circular reference
3. fixed and realized one only searched 1 manifest root
4. not investing the time to do that
5. fixed

[nagilson]

I was still able to confirm the fix worked for me

[nagilson]

Failures now are due to dotnet-watch