fix: event filtering edge case with no-op updates

[csviri]

When an event-filtering and caching update results in a no-op (i.e., nothing changes on the resource), and there is a concurrent update that actually modifies the resource, the event from that concurrent update may be filtered out.

This is particularly problematic when we patch the primary resource's status and the patch is a no-op, while another actor concurrently changes the resource's spec. In this case, the spec change would not result in an update event.

Although we could handle this particular case in the code, there are other situations (such as two concurrent updates to a secondary resource without optimistic locking) where we want to avoid similar issues. Therefore, we now limit event filtering to updates performed using optimistic locking.

We recognize that this changes the previous behavior. However, since controllers are expected to be idempotent by default, we do not expect this to have a significant impact on users.

In next minor version we will prepare enhanced methods that user can use to optimize their specific use cases:
#3483

Notes:

• added options for forcing event filtering, that is needed to preserve functionality for Dependent Resources. Where that behavior is actually correct, since we match the resources. This could be used also if somebody want to still use

TODO:

• update javadocs, documentation, release create post.