Add Zookeeper protocol checker with connection string support

[Copilot]

Pulse only did generic TCP checks for all services, including Zookeeper. This adds a proper Zookeeper-aware checker using the four-letter word (FLW) ruok/imok protocol, and supports the standard Zookeeper ensemble connection string format.

Changes

checker/zookeeper.go

• CheckZookeeperConnection(connectString, timeout) — parses a standard Zookeeper connection string (host1:2181,host2:2181,host3:2181[/chroot]) and returns nil if any node responds imok to ruok
• Falls back gracefully: a plain host:port is treated as a single-node connection string
• On total failure, reports all per-node errors for diagnostics

main.go

• Dispatches to CheckZookeeperConnection when service == "zookeeper"; all other services continue using the generic TCP checker

config.yml

• Zookeeper entries consolidated into ensemble connection string format:

zookeeper:
  - 10.0.1.27:2181,10.0.1.28:2181,10.0.1.29:2181

checker/zookeeper_test.go

• Tests for: successful handshake, unexpected response, connection refused, single host, partial ensemble availability, chroot stripping, empty input, and connection string parsing

[alanthssss]

@copilot
if we need remain the tcp network check? or just delete the old way
i want to know the best practce

[Copilot]

@copilot
if we need remain the tcp network check? or just delete the old way
i want to know the best practce

The generic TCP CheckConnection is intentionally kept — it's still used for every other service (Redis, Kafka, Elasticsearch, etc.). For Zookeeper specifically, the ruok/imok check replaces it rather than running in addition to it, because:

1. ruok already implies TCP reachability — checkZookeeperNode does net.DialTimeout first, so a failed TCP connection is still caught and reported as an error.
2. More meaningful signal — a port can be open (TCP succeeds) while Zookeeper itself is in an error state; ruok/imok verifies the process is actually healthy, not just listening.
3. No redundancy needed — running a plain TCP check and a ruok check on the same address would just report the same failure twice with different messages.

One caveat: Zookeeper ≥ 3.5 requires ruok to be explicitly whitelisted (4lw.commands.whitelist=ruok in zoo.cfg). If your deployment restricts four-letter words, the Zookeeper-specific checker will fail even when the node is healthy. In that case, falling back to the plain TCP check in checker.go for that service is the right call.

[alanthssss]

LGTM