Improve resiliency of upgrades

Currently when a user upgrades a cluster and any part of the process fails (lose connection to process, issue with environment, problem with template, networking issues, certs expiring during upgrade, etc.), the cluster is left at a broken state. This state results in not being able to run upgrade again, move management back to the cluster from kind, and use that cluster again for any administrative operations through EKS-A.

We need to prioritize the following items:
- [ ] Improve validations so we avoid failing in upgrade
- [ ] Improve checkpoint feature to handle more situations to restart flow from the middle
- [ ] Add ability to reverse steps of the workflow and bring back previous cluster state
- [ ] Improve documentation on disaster scenarios for users to follow
- [ ] Migrate existing self managed cluster to managed cluster

Start by mapping the cluster upgrade workflow and its checkpoint behavior, then review the validation, rollback, migration, and disaster-recovery areas described in the issue. Done means failed upgrades can resume or restore a previous cluster state, self-managed clusters can migrate to managed clusters, and users have recovery documentation for disaster scenarios.

Written by the indexing model from the issue text.