[FLINK-32012] Provide rollback feature on savepoint upgrade mode if HA missing and JM never started

[ashangit]

What is the purpose of the change

This pull request will provide rollback feature If the JobManagers have never started and we rely on savepoint upgrade mode. The operator will safely rollback relying on the provided savepoint

Also benefit from this change to unify rollback and upgrade code path

Brief change log

• Provide rollback feature on savepoint upgrade mode if HA missing and JM never started
• Unify rollback and upgrade code path

Verifying this change

(Please pick either of the following options)

This change is already covered by existing tests, such as (please describe tests).

• flink-kubernetes-operator/src/test/java/org/apache/flink/kubernetes/operator/controller/RollbackTest.java: Test different rollback cases

This change added tests and can be verified as follows:

• Manually verified the change by running a 4 node cluster with 3 JobManagers and 1 TaskManagers in standalone deployment mode:
  • First deployed a working app
  • Redeploy the app changing the parallelism to get 1 more TM
  • Then deploy the app by setting a not existing service account leading the JM to never start and requiring the job to be rolled back
  • Once rollbacked redeploy app decrease of parallelism and appropriate service account leading to app being redeployed

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changes to the CustomResourceDescriptors: yes but in status only adding lastRollbackSpec
• Core observer or reconciler logic that is regularly executed: yes

Documentation

• Does this pull request introduce a new feature? no
• If yes, how is the feature documented? not applicable

[gyfora]

I think this turned out to be a pretty nice and simple implementation piggybacking on the existing logic. However we should add some new test cases that cover the scenarios we wished to enable here in the first place.

[gyfora]

Can you please rebase it to the latest changes on master so we can run the e2es?

[ashangit]

There was an issue with new set of commits due to deployConfig being created too early and missing the potential reset of spec in case of rolling_back
Unittest updated by checking that the submitted config has well roll back a specific conf

[gyfora]

Thank you @ashangit for this great contribution :) good stuff