Set dockerImage in CR

[eberlep]

The Problem

Right now, on startup, the postgreslet first updates all postgres-operators, then continues to reconcile all postgresql custom resources.

Now when updating the spilo and the sidecars at the same time, each postgres cluster rolls once to reconcile the new sidecars (which will be automatically updated in the postgresql custom resource), then we need to restart the postgres-operator so it reads its updated configmap and updates the spilo image as well, meaning the postgres cluster rolls once more.

=> Two restarts and a manual step.

If we update the postgres-operator, spilo and the sidecars, the postgres-operator automatically restarts, sees its updated configmap with the new spilo image and starts rolling the postgres cluster. While that is happening, the postgresql custom resources are being updated with the updated sidecars, which also results in a rolling update. In the worst case, the reconcile fails because the postgres cluster is already rolling. (UpdateFailed)

=> Two restarts and (potentially) a manual step.

The main problem here is the fact that the spilo image and the sidecars are reconciled in different loops at a different time instead of doing just one update, and both changes might cause a rolling update of the postgres cluster.

The proposed solution

To solve that problem we could move the update of the postgres-operators into the regular reconcile loop of the postgresql custom resources (see #602). But that way we always run the postgres-operator update logic each time we reconcile the the custom resource, which is pointless because the operator is only ever updated when the postgreslet itself is updated, never at runtime.

The other solution is implemented here: Instead of moving the Postgres-Operator update into the regular reconcile loop, we simply separate the update of the postgres-operator and the update of the spilo image by specifically rendering the dockerImage into the postgresql custom resource.

That way, even if the postgres-operator is updated with a new spilo image first, it will not be applied until the regular reconcile loop runs (since the postgresql custom resource now also controls the spilo version). On top, there is no more need to restart the postgres-operator for it to read the updated configmap with a new spilo image, since it will be reconciled automatically once we update the custom resource.

=> Only one restart, no manual step. Also, way less changes in the code.