Add declarative `Publication` and `Subscription` support to the cluster chart

[spenc-r]

Summary

The CNPG operator supports declarative management of Publication and Subscription CRDs, but the cluster Helm chart currently has no way to render them. Users wanting native logical replication (e.g. for major-version upgrades or cross-cluster migration) have to drop down to raw manifests alongside the chart.

I'd like to propose adding first-class support to the cluster chart and am volunteering to do the work, opening this issue first per CONTRIBUTING.md to align on shape before submitting a PR.

Prior discussion

• Using Native Logical Replication with Current cnpg helm chart + external cluster usage in general #732: user asked for exactly this; closed stale without resolution.
• [Proposal] Coverage of all CNPG Operator options in cluster helm chart #692: broader chart-coverage proposal that lists publications/subscriptions among the gaps; closed stale.
• Bug: externalClusters configuration ignored in standalone mode (regression from PR #760) #831: open bug. Standalone mode strips externalClusters, which blocks the subscriber side of any cross-cluster logical replication.
• render custom externalClusters in standalone mode #832: open PR fixing Bug: externalClusters configuration ignored in standalone mode (regression from PR #760) #831 by allowing a raw cluster.externalClusters to render in standalone mode.

I have no maintainer signal that any of the above is being actively pursued; happy to coordinate if so.

Proposal

Add three things to the cluster chart:

1. publications: []: list rendering one postgresql.cnpg.io/v1 Publication per entry. Fields: name, dbname, target (allTables xor objects), optional parameters, publicationReclaimPolicy.
2. subscriptions: []: list rendering one Subscription per entry. Fields: name, dbname, publicationName, externalClusterName, optional parameters, subscriptionReclaimPolicy.
3. A way to declare the source cluster connection for Subscription.externalClusterName. See open question below.

Plus: documentation page, two examples (publisher / subscriber), and a chainsaw test that stands up two clusters, replicates rows, and asserts row counts on the subscriber.

Open question: connection-config shape

There are two reasonable places for the externalCluster connection to live:

Option A: typed logicalReplication.externalClusters (what I prototyped):

logicalReplication:
  externalClusters:
    - name: source-cluster
      host: source-rw.default.svc
      port: 5432
      username: app
      database: app
      sslMode: verify-full
      passwordSecret: { create: false, name: source-app, key: password }
      sslRootCertSecret: { name: ..., key: ... }

Pros: helm-validated schema, optional secret creation (create: true with value:), familiar shape (mirrors recovery.pg_basebackup.source).
Cons: duplicates the CNPG externalClusters schema.

Option B: reuse cluster.externalClusters from #832
Once #832 lands, users put the full upstream externalClusters entry directly into cluster.externalClusters and reference it by name from subscriptions[].externalClusterName.
Pros: single source of truth, no schema duplication, automatically inherits any new CRD fields.
Cons: no helm-side validation, no convenience secret creation; users hand-write the full CNPG shape.

I have a working implementation of Option A but am happy to rework to Option B (or a hybrid where Option A renders into the same externalClusters list #832 introduces). What's your preference, @itay-grudev?

What I have ready

A working branch with:

• the three template files,
• values.schema.json updates,
• helm-docs-regenerated README,
• examples for publisher and subscriber,
• three chainsaw tests (logical-replication, logical-replication-objects, logical-replication-schema) covering allTables, specific objects, and schema-scoped publications, with test-style assertions on row counts and replicated objects.

I'll rebase onto current main, sign off commits per DCO, and open the PR as dev/<this-issue-number> once the shape question is resolved.

Out of scope (for this issue)

• The standalone-mode externalClusters rendering itself, tracked in Bug: externalClusters configuration ignored in standalone mode (regression from PR #760) #831 / render custom externalClusters in standalone mode #832.
• Replica clusters / replica.origin changes, separate concern.
• Plugin-based logical replication (if/when CNPG adds it).