PMM-14738 Validate PMM HA replica counts and publish the supported range

[theTibi]

PMM-14738

Adds the validation and documentation for PMM HA scaling that the chart never had, plus the test suite that guards it.

Nothing checked the two values that can break a cluster

Rendered at replicas 1 through 12, everything was accepted silently:

replicas	Raft peers	HAProxy slots	Warning
2	2	10	none
4	4	10	none
12	12	10	none

• Even counts. Raft elects by majority, so 4 replicas need more votes to elect a leader without surviving more losses than 3 do, and replicas=2 survives none — one pod restart stops the cluster.
• Above maxReplicas. HAProxy renders server-template pmm 1-<maxReplicas> and fills the slots from a headless-service DNS answer in arbitrary order, then marks a backend UP only when it answers /v1/server/leaderHealthCheck. A pod without a slot is invisible to HAProxy — and if the Raft leader lands there, every backend is DOWN and PMM serves 503. Not a degraded pod: an outage.

pmm.replicas.validate and pmm.keeper.validate now reject both, plus malformed input. The regex is strict on purpose: sprig's int parses base 0, so "010" would have validated as 8, and anything wider than int64 overflows to 0 — either way the error would quote a number nobody typed.

Suggestions are clamped to the ceiling, so the error never names a value the next check rejects:

replicas=2   Use 1 or 3.
replicas=4   Use 3 or 5.
replicas=10  Use 9.
replicas=12  maxReplicas is 10, so the largest supported value is 9.

clickhouse.keeper.replicasCount is a Raft ensemble too. values.yaml has always said it "should be odd"; that is now enforceable rather than advisory.

Smaller fixes

• maxReplicas had its | default 10 duplicated between the validator and haproxy-configmap.yaml. Both now read pmm.maxReplicas, so they cannot drift — and because default treats 0 as empty, maxReplicas: 0 used to become 10 silently.
• The workflow's paths: filter did not include the workflow file, so a PR editing only its assertions ran no job.
• azure/setup-helm v4.2.0 / Helm 3.15.4 -> v5.0.0 / Helm 3.21.0, which is what the helm-unittest plugin needs to load.

Tests

charts/pmm-ha/tests/ — 27 helm-unittest cases, no cluster required, runnable with make test-pmm-ha:

Test Suites: 3 passed, 3 total
Tests:       27 passed, 27 total

Scoping a suite to templates/statefulset.yaml skips the lookup in pg-user-credentials-secrets.yaml entirely, so these do not depend on Helm's template ordering the way a helm template assertion would.

Mutation-tested against the merged tree — every regression is caught:

Mutation	Result
revert pmm.haPeers to .Release.Name	2 failed
revert the server-template slot count to a literal 10	2 failed
drop the even-count check	5 failed
make pmm.validate.oddCount always reject	20 failed, 5 errored
drop the maxReplicas ceiling check	2 failed

Merged with PMM-HA-GA

Merging the current base branch dropped two changes this PR originally carried, because equivalent work landed first:

• The PMM_HA_PEERS fix. pmm.haPeers built peer hostnames from .Release.Name while the StatefulSet is named after pmm.fullname, and the two are equal only when the release name already contains the chart name — so helm install pmm-prod percona/pmm-ha gave Raft peers that never resolved. PMM-15151: make PG and ClickHouse operators watch all namespaces #868 (PMM-15151) shipped the same fix, so there is nothing left to change here. tests/ha-peers_test.yaml stays as the regression guard, including a case asserting that a release named pmm-ha still renders byte-identically.
• ci/ci-values.yaml. This PR removed clickhouse.keeper.replicas, a key nothing reads (the template reads replicasCount). PMM-15441 Fit the pmm-ha CI install back onto the Kind node #946 (PMM-15441) rewrote the file and already sets replicasCount.

templates/haproxy-init-configmap.yaml was deleted by #937 (PMM-15394), and this PR's pmm.fullname fix to its host loop went with it. The chart version conflict resolved to 1.7.0, keeping appVersion "3.9.1" from #937.

Upgrade impact

Breaking for anyone running an even replicas. 2 or 4 was accepted before and now fails the render; those users must set an odd value in the same helm upgrade, which recreates the pods. The README carries an upgrade note.

Chart 1.6.2 -> 1.7.0. Reviewers: a case can be made for 2.0.0 — a ^1.6.2 consumer will otherwise adopt a render-breaking change automatically. Happy to bump if you prefer.

Related

• Documentation half: PMM-14738 Document the supported PMM HA scaling range and its limitations pmm#5842