Today, the KafkaRoller does not handle well when the pods are not ready when the rolling update check starts. When the pods are not ready for example because they are still starting, the Roller will roll them just because they are not ready because it cannot really connect to them.

That has several side effects. One of them is for example described in SP#048 and deals with issues when the broker needs a lot of time to recover files after an unclean shutdown.

Another one - on which this PR focuses - is the split of PodSet update, rolling update, and scale-up. The reconciliation flow today is as follows:

• (N) Update the PodSet, but do not scale it up (i.e. add any new pods) -> update only the YAMLs for the existing pods. If it is the first reconciliation and the pods are being created, we have to wait for readiness in this step before letting the KafkaRoller check the pods.
• (N+1) Check the existing pods for rolling update
• (N+2) Scale up the Kafka cluster (update the PodSet again to add new pods)

This logic was reasonably straightforward with StatefulSets where we had a single template and the scale-up or not was just about setting the right number of replicas. But with StrimziPodSets, this requires more complexity because it is not just changing the number of replicas. It actually needs the new pods to be generated. And in the future with things such as non-continuous node IDs and the KRaft architectures, or things such as node pools, this might become even more complex.

Moving this logic into the KafkaRoller would allow us to simplify the scale-up and rolling update process of Kafka.