Provide the ability to add custom health checks that precede and follow ClickHouse reconfiguration/upgrade

We had a recent discussion with a user who has the following use case. They have an operator that watches for replication lag on ClickHouse and only schedules upgrade when it's below a certain level. They were wondering if the operator could help them implement logic that amount to "guard conditions" on operator upgrades. It could work as follows:

1. Permit a ClickHouse replica upgrade operation to start when replication lag is below a "reasonable" level.
2. Confirm that the replication lag is back to a reasonable level before moving to the next replica.

In this case the guard condition is replica lag but it's likely that there would be others. They and other users would presumably want to customize the conditions.

It seems as if this could be implemented in a general way by adding a custom health check section to CHI instances that contain one or more SQL queries to run before and after upgrade. If the check(s) pass, the upgrade could proceed. If they fail the operator would wait.

There are some questions with this kind of guard that we need to contemplate.

1. How would other services learn the status of the cluster health checks?
2. What happens if replica lag increases suddenly during an upgrade? It could block an incomplete operation indefinitely.
3. Does it just apply to upgrade or to any reconfiguration that causes a pod restart?
4. Should we report these health check results in our exported metrics? It would be important to see these visually in, say, Grafana when kicking off an upgrade or diagnosing problems.

No files, tests, or entry points are named. Start by reviewing the four design questions in the issue and the operator's existing reconfiguration and upgrade behavior. Done means an agreed design for custom pre- and post-operation checks, failure handling, status visibility, and metric reporting.