feat(api): support externally managed Keeper clusters

[melancholictheory]

Why

ClickHouseClusterSpec requires keeperClusterRef, which ties a ClickHouse cluster to a KeeperCluster this operator owns. Plenty of people already run Keeper somewhere else: managed by a different operator, in another Kubernetes cluster, on VMs or bare metal, or shared between several systems. Until now there was no way to point ClickHouse at one of those.

What

Adds spec.externalKeeper and makes spec.keeperClusterRef optional. The validating webhook requires exactly one of the two, so existing clusters behave exactly as before and neither field can be silently omitted.

spec:
  externalKeeper:
    nodes:
      - host: keeper-1.example.internal
        port: 9181

port defaults to 9181. TLS is an ensemble-level tls: Enabled|Disabled enum rather than a per-node boolean, because crd-schema-checker rejects newly added boolean fields under its NoBools rule. It also matches how the operator already treats its own Keeper, where TLS is uniform across the ensemble.

When externalKeeper is set, the operator:

• builds the zookeeper config section from the listed nodes,
• skips fetching the KeeperCluster object and its readiness check, since it does not own that lifecycle,
• skips the pod affinity rule that co-locates ClickHouse pods with Keeper pods.

Keeper authentication is unchanged. The identity still comes from the keeper-identity key of the cluster Secret, so an external ensemble works through the existing mechanism.

keeperClusterRef became a pointer. As a value struct it would serialize to keeperClusterRef: {} when unset, which the CRD rejects because name is required inside it. KeeperClusterReference.NamespacedName already had a nil check, so the call sites did not need changing.

Dropping keeperClusterRef from the CRD required list only relaxes the schema; make check-crd-compat passes against main.

Docs get a new "Externally managed Keeper" section in the configuration guide.

Testing

Unit tests cover all four combinations of the two fields in the validating webhook, the CRD defaults, and config generation for both plain and TLS ensembles.

I also ran it on a live k3d cluster:

• a 2-replica cluster using externalKeeper reaches Ready, zookeeper.nodes renders the given hosts, and podAffinity is absent from the StatefulSet,
• a row inserted on replica 0 reads back from replica 1, so coordination through the external ensemble genuinely works,
• a cluster using keeperClusterRef still reaches Ready and still gets the Keeper podAffinity,
• the webhook rejects a CR that sets both fields and one that sets neither.

Related Issues

Fixes #285

[CLAassistant]

All committers have signed the CLA.