K8SPG-882 determine patroni version without using the special patroni version check pod

[gkech]

CHANGE DESCRIPTION

Problem:

The current patroni version check implementation can be completely skipped. We can assume by default patroni version 4.x and utilize the custom version annotation if we want to specify an older or a later one e.g. 3.x. The version configured is going to appear to the PG object status and also used to determine the primary pod for postgres - because =<3.x patroni versions utilize the master terminology while never versions (4.x) utilize the primary terminology. If the annotation is not used, the operator gets the patroni version from patronictl version through an instance pod.

For instance, configuring an instance image version which is using patroni 3.x. but specifying a patroni version which is newer, will appear in the status like that and will cause the operator to try to find primary with the primary terminology. And vice versa, using patroni 4.x and configuring the labels to use an older patroni version than 4.x, will cause the operator to try to find the primary using the master terminology. These scenarios can cause problems and should be avoided.

Cause:
Short explanation of the root cause of the issue if applicable.

Solution:
Short explanation of the solution we are providing with this PR.

CHECKLIST

Jira

• Is the Jira ticket created and referenced properly?
• Does the Jira ticket have the proper statuses for documentation (Needs Doc) and QA (Needs QA)?
• Does the Jira ticket link to the proper milestone (Fix Version field)?

Tests

• Is an E2E test/test case added for the new feature/change?
• Are unit tests added where appropriate?

Config/Logging/Testability

• Are all needed new/changed options added to default YAML files?
• Are all needed new/changed options added to the Helm Chart?
• Did we add proper logging messages for operator actions?
• Did we ensure compatibility with the previous version or cluster upgrade process?
• Does the change support oldest and newest supported PG version?
• Does the change support oldest and newest supported Kubernetes version?

[egegunes]

@gkech please check unit tests

[JNKPercona]

Test Name	Result	Time
backup-enable-disable	passed	00:10:10
custom-extensions	passed	00:15:57
custom-tls	passed	00:05:54
database-init-sql	passed	00:03:22
demand-backup	passed	00:26:27
finalizers	passed	00:04:03
init-deploy	passed	00:03:11
monitoring	passed	00:08:58
monitoring-pmm3	passed	00:09:25
one-pod	passed	00:06:05
operator-self-healing	passed	00:08:42
pgvector-extension	passed	00:02:47
pitr	passed	00:12:01
scaling	passed	00:05:13
scheduled-backup	failure	00:37:43
self-healing	passed	00:09:18
sidecars	passed	00:02:37
start-from-backup	passed	00:12:54
tablespaces	passed	00:07:29
telemetry-transfer	passed	00:03:35
upgrade-consistency	passed	00:10:28
upgrade-minor	passed	00:05:31
users	passed	00:04:58

Summary	Value
Tests Run	23/23
Job Duration	02:09:08
Total Test Time	03:37:00

commit: baeed56
image: perconalab/percona-postgresql-operator:PR-1334-baeed56a1