[omkar619-dev]

Adds a replicaConnectionPooler section to the Postgres manifest so the replica pooler can be configured independently of the master pooler.

The new type carries numberOfInstances, mode, dockerImage, maxDBConnections and resources. It deliberately does not carry user or schema: those are cluster-scoped rather than per-pooler. The two places that read them — poolerUser, and the lookup-function install in syncConnectionPooler — create objects once per cluster that both poolers share, so leaving those two fields out means neither site has to become role-aware.

Fields are pointer-typed so unset means "inherit from connectionPooler" rather than "zero". A manifest using enableReplicaConnectionPooler: true with only a connectionPooler section behaves exactly as it does today.

How it works

effectiveConnectionPoolerSpec(spec, role) resolves the settings for a role: master returns connectionPooler unchanged, replica returns connectionPooler with any field explicitly set in replicaConnectionPooler laid over it. It returns the existing ConnectionPooler type, so needSyncConnectionPoolerSpecs and needSyncConnectionPoolerDefaults keep their signatures, and it never returns nil, which replaces a nil check that four call sites each repeated.

Those four are getConnectionPoolerEnvVars (the only signature change — it gains the role, and has a single caller), generateConnectionPoolerPodTemplate (already took the role and ignored it), generateConnectionPoolerDeployment
(has it via connectionPooler.Role), and the spec comparison in syncConnectionPoolerWorker.

That last one though is the subtle one. If the comparison keeps looking only at spec.ConnectionPooler, editing replicaConnectionPooler on a live cluster produces no diff, the deployment is never regenerated, and the replica pooler
silently keeps its old settings — correct on create, inert on update. TestReplicaConnectionPoolerSyncOnOverrideChange drives syncConnectionPooler against the fake client and asserts the replica deployment moves from 2 to 4
instances while the master stays at 2. I confirmed it fails (expected 4, actual 2) with the role argument removed.

Also included

• TestEffectiveConnectionPoolerSpec: six cases covering inherit, partial override, full override and the empty-section cases.
• Regenerated CRD schema (all three copies) and deepcopy.
• Docs: a replicaConnectionPooler section in the manifest reference, an example in the user guide, and a commented block in the complete manifest.

Left out deliberately

Setting connectionPooler on its own implicitly enables the master pooler, but there is no replica equivalent, so enableReplicaConnectionPooler remains required and a replicaConnectionPooler section alone won't switch anything on.
That felt outside the scope of this change, but happy to make the two symmetric if you'd prefer.

Closes #3113

[omkar619-dev]

The End-2-End failure here doesn't look like it comes from this branch, though I'd welcome a correction.

It fails in test_major_version_upgrade, on "AssertionError: Annotation for last upgrade's success is not updated". The same test also fails on master at b217b45, which is this PR's base: that run started about a minute before this
one and failed on a different assertion inside the same test ("14 != 15 : Version should be upgraded from 14 to 15"). Of the last ten End-2-End runs on master, six are red.

This branch only touches the connection pooler, the CRD schema, deepcopy and the docs, so I can't see a route from it to a Postgres major version upgrade.

If it would help, I'm happy to merge master in again to re-trigger the job once master is green — I'd rather do that than rebase, so the branch keeps the maintainer merge commits already in it.