Support SSA in InformerEventSource, listen to specific status updates

[bertdw-1985]

Is your feature request related to a problem? Please describe.
I am working on a multi-reconciler setup (Main and Secondary) managing the same Custom Resource. The Secondary reconciler updates a specific field within the resource's .status using Server-Side Apply (SSA). The Main reconciler needs to be notified and triggered only when the resource's generation changes OR when this specific status field is updated by the Secondary reconciler.

Currently, achieving this cleanly is not possible:

• If generationAwareEventProcessing is set to true, the Main reconciler completely misses the status updates.
• If generationAwareEventProcessing is set to false, the Main reconciler is triggered far too often by unrelated status updates.
• Attempting to pass a custom OnUpdateFilter via the ControllerConfiguration fails because custom filters are combined with JOSDK's internal filters using a strict AND operation. This prevents implementing a logical OR condition (e.g., DefaultFiltering OR SpecificStatusFieldChanged).

Describe the solution you'd like
I would like a way to configure the controller's event filtering behavior to allow logical OR operations between the internal filters (like generation-aware filtering) and user-defined custom filters.

Alternatively, a feature allowing developers to keep generationAwareEventProcessing = true but explicitly define a list of observed status paths (e.g., status.mySpecificField) that should bypass the generation-aware restriction and still trigger an event would elegantly solve this use case. Or another way to achieve this.

Describe alternatives you've considered

1. Setting generationAwareEventProcessing to false: This causes performance degradation due to a flood of redundant reconciliation loops from other status updates.
2. Creating a separate EventSource on our own resource with an OnUpdateFilter: While this successfully isolates the specific status change, it introduces two major downsides:

• It forces the creation and maintenance of an unnecessary secondary cache.
• In JOSDK v5.2.0, it introduces read-after-write inconsistencies where the resource instance passed to the Main reconciler is outdated at the moment the event source triggers it.

Additional context

• Environment: Java, Micronaut, JOSDK v5.2.0.
• This issue is particularly relevant in advanced operator patterns where responsibilities are split across a Main and a Secondary controller for the same CRD, relying on status fields to pass state back to the primary loop.

[csviri]

Hi @bertdw-1985 , thank you for reporting this, makes sense, will come back to this bit later, and we will cover this for sure.

@xstefank or @metacosm if you have the bandwidth please take a look, I'm bit overwhelmed with other issues atm.