Declarative support for PostgreSQL major online upgrades

[gbartolini]

Currently, Major upgrades of PostgreSQL can be done in an imperative way, by relying on the native logical replication capabilities and the cnpg plugin. See: https://www.gabrielebartolini.it/articles/2024/03/cloudnativepg-recipe-5-how-to-migrate-your-postgresql-database-in-kubernetes-with-~0-downtime-from-anywhere/

However, we should provide a way to support major upgrades just by changing the major field like in the following example:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
spec:
  instances: 3
  imageCatalogRef:
    apiGroup: postgresql.cnpg.io
    kind: ImageCatalog
    name: postgresql
    major: 16
  storage:
    size: 1Gi

To:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
spec:
  instances: 3
  imageCatalogRef:
    apiGroup: postgresql.cnpg.io
    kind: ImageCatalog
    name: postgresql
    major: 17
  storage:
    size: 1Gi

Alternative approaches are valid too, for example through CRDs that evoke imperative names (like upgrades) and that are useful too as they prepare the underlying PVCs for the new major.