Remove CHECK_FOR_UPGRADES and registration

[jmckulk]

Checklist:

• Have you added an explanation of what your changes do and why you'd like them to be included?
• Have you updated or added documentation for the change, as applicable?
• Have you tested your changes on all related environments with successful results, as applicable?
  • Have you added automated tests?

Type of Changes:

• New feature
• Bug fix
• Documentation
• Testing enhancement
• Other

What is the current behavior (link to any open issues here)?

What is the new behavior (if this is a feature change)?

• Breaking change (fix or feature that would cause existing functionality to change)

Other Information:

[ctrought]

FYI / heads‑up for anyone who encounters the following warning when running multiple PGO instances at different versions:

level=info msg="unknown field \"status.registrationRequired\"" version=5.5.1-0-amd64

This occurs due to a schema change in the status section of the PostgresCluster CRD. When OLM manages multiple operator installations at different versions (e.g., multi‑tenant clusters using namespace‑scoped installs), the following scenario can break reconciliation:

1. Operator Instance A is upgraded to a newer version.
2. OLM updates the shared CRD to the latest API definition, removing fields (such as status.registrationRequired) that no longer exist in the new schema.
3. Operator Instance B, still running the older version, continues to emit these fields in its status updates.
4. Kubernetes rejects those updates, resulting in the unknown field error and Instance B fails to reconcile and breaks operator functionality for instance B.

Workaround:

Upgrade Operator Instance B so all operator installations run the same CRD version.

While the assumed deployment model is likely one PGO instance per cluster, OLM technically supports multiple namespace‑scoped operator installations which is a common pattern for multi‑tenant clusters. Without versioned CRD APIs, any breaking change in the shared CRD can affect older versions of the operator running in the same cluster.

Suggestion:

For changes that remove or alter CRD fields, would be ideal to bump the CRD API version to avoid breaking older operator versions still in use in the same cluster.