[ENH] Update upgrade command mechanics after migration

[viniciusdc]

After migrating qhub to nebari, we should review upgrade logic mechanics to accept qhub-config.yaml and nebari-config.yaml files and the different version schematics. Or remove it

[viniciusdc]

Ok... so this mechanic was created to help the user migrate Qhub (v0.3.*) to (v0.4.0)... but we stopped maintaining it since v0.4.3.

In theory, for each new release that changed or added some requirements to the qhub-config.yaml, the upgrade command would be able to easily update the config when updating the version... but I am not sure if we've been using it.

So, now that we are migrating to calver/Nebari and we are almost very far away from v0.3.*, I would like to raise the possibility of removing this functionally as, at least in my opinion, this looks deprecated now.

If we opt for maintaining this, then we will need to refactor it to accommodate the upgrade steps from Qhub(0.3.* -> 0.4.5) as well as Qhub (v0.4.5) -> Nebari 2022.10.1 (and future releases), which comprehends the following changes:

• a logic conditional to check for qhub-config and nebari-config
• A refactor in the whole mechanic... if the package name matches nebari upgrade should behave differently and upgrade the config contents based on 2022.10.1 nebari-qhub.yaml file, not based on a qhub-generated one.

[iameskild]

For the past few releases we have updated the upgrade command while retaining the old qhub upgrades. Closing this issue.