Refactoring and Cleanup code

[ccremer]

Summary

Refactored the standalone pipelines:

• New package steps contains all "business steps" that can be reused to some extend.
• Some of the steps require additional objects to be present in the context. They are at the top of the function as a variable, so it should be relatively easy to figure out which objects are required by which step.
• As such, some steps require a certain order resp. depend on each other.
• The "creating" condition is gone. There's now only "Ready" and "Progressing" conditions, even for first-time reconciliations.
• Implementation detail: We compute the hash sum of the Helm values if they existed before. This is required to figure out if there was a change in the Helm values. And we need that to determine whether the timestamp in the "Ready" condition in the Helm release CRD is legit or not. Without this mechanism, our operator may conclude that the Helm release is already ready, even if we just updated it a few milliseconds before.

The "create" and "update" have been consolidated, there is now just 1 pipeline. This makes it easier to understand, the pipeline also follows better the idempotency design as expected by Kubernetes. Also, there is no "first" and "2nd pass" anymore to determine the readiness of dependent resources.

The result is a lot less code to understand and maintain overall, at the cost of somewhat added complexity for idempotency in the individual steps.

Functionally, no changes are expected.

Checklist

• [x] Categorize the PR by setting a good title and adding one of the labels: bug, enhancement, documentation, change, breaking, dependency as they show up in the changelog
• [x] PR contains the label area:operator
• [ ] Link this PR to related issues
• [x] I have not made any changes in the charts/ directory.

[ccremer]

as discussed internally, we'll not do a full code review here. It has been tested though and it seems to be working more stable than with different pipelines and "passes"