Always resolve SCYLLA_OPERATOR_IMAGE to sha reference

[tnozicka]

Is this a bug report or feature request?

• Feature Request

What should the feature do: If someone useses a rolling update tag like latest or 1.3 for SCYLLA_OPERATOR_IMAGE, we won't initiate a rolling restart to update the sidecar image. We should always use sha in the objects we generate even if the user forgot to do so.

[rzetelskik]

@tnozicka why would we want to initiate a rolling restart whenever a new image is published using an existing tag? I've consulted this behaviour with @zimnx and he expressed concern as well.

[tnozicka]

the operator image is embedded in every scylla deployment for the side car so if the user:

1. deploys the operator with latest, currently pointing to 1.4.0
2. deploys a ScyllaCluster with 3 replicas, sidecar get's the image for 1.4.0
3. :latest changes to 1.5.0
4. :latest changes to 1.6.0
5. now you have an unsupported skew because the image is effectively not reconciled
6. one of the scylla pods gets evicted and the new pod resolves to 1.6.0 while the other two still run from 1.4.0

similar issues arise for the case when a tag is rewritten, sha is the only way to reliably reference the same image

[scylla-operator-bot[bot]]

The Scylla Operator project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 30d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out

/lifecycle stale

[tnozicka]

This may be be replaced by splitting this logic into a separate image but until we have a plan for that let's keep this here. /remove-lifecycle stale