Implement all agreed changes in RollingUpdateST. 

• testRecoveryDuringZookeeperRollingUpdate
  • check that only 1 zk pod is in pending state even after second reconciliation
• testRecoveryDuringKafkaRollingUpdate
  • check that only 1 Kafka pod is in pending state even after second reconciliation

• testKafkaAndZookeeperScaleUpScaleDown
  • enable this test to kraft if possible
  • scale kafka only to 5 rep. (to save time/resources)
  • After Kafka scale create new topic with replicas on newly added brokers (cannot easilly scaledown after that - remove topics should handle it)
• testZookeeperScaleUpScaleDown
  •  Create new topcis after ZK scale operation and attach clients to it to see if the ZK works correctly
• testBrokerConfigurationChangeTriggerRollingUpdate
  • see how this triggering by change of config is covered in diff. test suits. 
• testManualKafkaConfigMapChangeDontTriggerRollingUpdate
  • remove this test
• testExternalLoggingChangeTriggerRollingUpdate
  • rename test according to what is happening in steps. 
  • consider migration to logging test suite 
• testClusterOperatorFinishAllRollingUpdates
  • Try to dig form the history why we have there check for pending state of Kafka pods and why we delete CO twice
• testMetricsChange
  • move to metrics? 
  • deploy Kafka with disabled metrics and then enable it to see it will trigger rolling update