Fix read replica reconcile status handling

[hhhizzz]

Summary

Fixes #47.

This change makes read replica reconciliation use read-replica-aware cluster metadata instead of treating all instances as Group Replication members.

Specifically, it:

• Detects existing async read replicas under Cluster.status({"extended": 1}).defaultReplicaSet.topology[*].readReplicas, so an OFFLINE replica already present in cluster metadata is classified as REJOINABLE instead of JOINABLE.
• Updates read replica membership/readiness probing to use AdminAPI cluster status rather than performance_schema.replication_group_members, which does not contain async read replicas.
• Writes read replica pod membership annotations and readiness gates from the read-replica-aware status source.
• Adds regression coverage for both the rejoin classification and readiness update paths.

Root Cause

The existing reconcile path had two GR-member assumptions:

1. diagnose_cluster_candidate() only checked top-level topology keys, which cover GR members but not async read replicas.
2. probe_member_status() always used query_membership_info(), which queries performance_schema.replication_group_members; async read replicas are absent from that table and were therefore reported as OFFLINE.

Testing

• python3 -m unittest discover -s tests/unit -p 'test_read_replica_reconcile.py' -v
• python3 -m py_compile mysqloperator/controller/diagnose.py mysqloperator/controller/innodbcluster/cluster_controller.py tests/unit/test_read_replica_reconcile.py
• git diff --check

[mysql-oca-bot]

Hi, thank you for submitting this pull request. In order to consider your code we need you to sign the Oracle Contribution Agreement (OCA). Please review the details and follow the instructions at https://oca.opensource.oracle.com/
Please make sure to include your MySQL bug system user (email) in the returned form.
Thanks