Fixes when deploying/upgrading the OneAgent using immutable images

[lrgar]

This PR fixes two issues when using immutable images:

• No longer check for the cluster version before deploying the OneAgent.
  • If the reconciliation was taking long enough (~5 mins) prior to this check, the Operator ended up not deploying the DaemonSet at all.
  • This can be caused by having a slow connection to the corresponding API URL, and having features such as Istio enabled, since there are a few extra requests before we look at the cluster version.
  • Since this logic was implemented when we were considering having immutable images as default, which we ended up not doing so, we can just remove the logic. cr.yaml has the minimum OneAgent/cluster version requirements.
• Keep the latest version of the OneAgent as an Pod annotation when using immutable images.
  • We were currently looking at the image digest from what it's currently running to what it should be on the cluster. This may trigger upgrades even when there are no changes on the version (e.g., changes on communication endpoints.) The OneAgent already keeps track of it and keeps it on disk, so there is no need to go that far.
    • This new change can be an issue if the customer doesn't have connectivity in first place. The customer can restart the Pod manually in this case.
  • With the Pod annotation then, on upgrades, the Operator will update the DaemonSet, who will then restart the Pods itself. Similar to what we do for the StatefulSets with the Dynatrace Operator.
    • waitReadySeconds is ignored for this.
    • New update rollouts won't happen if the DaemonSet is in a bad state (e.g., Openshift customer not having Namespace's node selector matching the OneAgent CR's node selector.) Although the customer would be having other issues in this case regardless.

I ended up removing a lot of code that is no longer used.