audit/cleanup for basic upgrade validation

[joel-bluedata]

Part of issue #588.

Now that everything is in the live-app-upgrade branch there's some massaging probably needed in the validation code.

First there's the validation for triggering an upgrade or rollback. I'll restate/collapse the criteria together a bit here, throw in some broad categories, and include the parts of the "more strict" validation checks we decided on which apply during this initial trigger.

• If the kdapp in the kdcluster spec is being changed:
  • Check kdcluster state:
    • Is the kdcluster ready (in a configured state)? If not, reject.
  • Check validity of the requested kdapp:
    • Does the new kdapp have the same distroID as the current one? If not, reject.
    • Does the new kdapp have a different version than the current one? The doc says ignore here, but the current reject approach is probably better (can discuss this elsewhere).
    • Does the new kdapp indicate that it supports live upgrade? If not, reject.
  • Check current upgrade/rollback state:
    • If a rollback is in progress, reject.
    • If an upgrade is in progress, but we are NOT returning to the previous kdapp, reject.
    • If any other spec changes are also being requested along with the kdapp change, reject.

Then there's the other half of the "more strict" validation checks we decided on:

• If the kdapp is NOT being changed:
  • If an upgrade or rollback is in progress, reject any spec changes.

So, this is what we want to implement. Let's see if we got there!

I think there are some spots where validateGeneralClusterChanges doesn't match up with this. For example it will reject any spec change other than kdapp if the kdcluster is not in a configured state, which is too strong and rejects some valid changes as we discussed in the meeting. As per above, those spec changes are only bad if kdapp is being changed or if an upgrade/rollback is already in progress.

Other than that I think it matches though? Or at least is very close. Some checks are done in a different order so I might not have judged it all correctly, but the other checks seem to be in there.

A good audit pass over the changes to validateGeneralClusterChanges to compare against these requirements will be helpful.

There are some additional checks we'll want, but I'll file those as separate issues that depend on this one.