Add observedGeneration while updating the ApicurioRegistry3's status

[kamolhasan]

This pull request refines the status management logic in the StatusManager class to ensure the observedGeneration field is updated accurately and reflects the latest resource version. The changes improve the reliability of status updates for the ApicurioRegistry3 resource.

Background Context

The ApicurioRegistry3 operator is exhibiting unexpected behavior where the status.observedGeneration field is being removed and then immediately re-added in subsequent reconciliation loops. This pattern results in frequent MODIFIED events, each triggering a new resourceVersion in etcd:

• observedGeneration is removed by the operator.

• A follow-up event adds the same observedGeneration back.

• Each of these changes results in a new resourceVersion.

2025/06/26 15:05:34 === APICURIOREGISTRY3 MODIFIED EVENT ===
2025/06/26 15:05:34 Resource: default/apicurio-registry
2025/06/26 15:05:34 Timestamp: 2025-06-26T15:05:34+07:00
2025/06/26 15:05:34 Kind: ApicurioRegistry3
2025/06/26 15:05:34 APIVersion: registry.apicur.io/v1
2025/06/26 15:05:34 Event: ApicurioRegistry3 modified
2025/06/26 15:05:34 Status changes (-old +new):
  map[string]any{
        "conditions":         []any{map[string]any{"lastTransitionTime": string("2025-06-26T07:37:20Z"), "lastUpdateTime": string("2025-06-26T07:37:20Z"), "message": string("All active Deployments are available."), "reason": string("ActiveDeploymentsAvailable"), ...}},
-       "observedGeneration": int64(1),
  }
2025/06/26 15:05:34 ResourceVersion changed: 151704 -> 152413
2025/06/26 15:05:34 === END EVENT ===
2025/06/26 15:05:34 === APICURIOREGISTRY3 MODIFIED EVENT ===
2025/06/26 15:05:34 Resource: default/apicurio-registry
2025/06/26 15:05:34 Timestamp: 2025-06-26T15:05:34+07:00
2025/06/26 15:05:34 Kind: ApicurioRegistry3
2025/06/26 15:05:34 APIVersion: registry.apicur.io/v1
2025/06/26 15:05:34 Event: ApicurioRegistry3 modified
2025/06/26 15:05:34 Status changes (-old +new):
  map[string]any{
        "conditions":         []any{map[string]any{"lastTransitionTime": string("2025-06-26T07:37:20Z"), "lastUpdateTime": string("2025-06-26T07:37:20Z"), "message": string("All active Deployments are available."), "reason": string("ActiveDeploymentsAvailable"), ...}},
+       "observedGeneration": int64(1),
  }
2025/06/26 15:05:34 ResourceVersion changed: 152413 -> 152417
2025/06/26 15:05:34 === END EVENT ===

These seemingly redundant modifications cause unnecessary propagation of updates to dependent deployment objects (app, ui) through the annotation: javaoperatorsdk.io/previous: ... ...

Each event causes the operator to patch these deployments even though there is no actual configuration change, resulting in noise and inefficiency.

[kamolhasan]

#6366

[jsenko]

Thank you for the PR, this is interesting because the observed generation should be managed automatically by the Java Operator SDK. It seems like it's not doing that properly.

[kamolhasan]

Thanks @jsenko

Java is not my core programming language, so I'm not sure how to resolve the failing GitHub Actions test suites. If you’d like, you can take over this PR, or feel free to close it and include this change in one of your future PRs.

[jsenko]

Should be addressed by #6409 . We're upgrading to new major version of JOSDK where observed generation management is done manually.