Enhanced mode(s) in ResourceOperation #3483

Recently we changed event filtering, see details here: #3484
That bit limits the capabilities of this feature.

In next minor version we could still provide improved alternatives in ResourceOperations that user can use to optimize their specific use cases.

Prevent no-op updates

Things to consider regarding this enhancement:

1. Users ideally do just updates/patches on resources when the desired state of those resources are not in the desired state.
2. We discovered an issue with event filtering, it only works reliable in all the cases when the update changes the resources (so results in a bump in resource version)

Introducing an update mode for methods in ResourceOperations , that will match the current state with desired state and executes the patch only those cases, would handle these two situations optimally.

We already have such matchers implemented and battle tested partially (not for status updates) for dependent resources, so we can just reuse them here.

Explicit cache-only methods

User would have an option to explicitly set to not filter the events just cache the resource.

Other Remarks

• In UpdateControl we still have .patchResource and .patchResourceAndStatus. In future we might:
  1. want to deprecated this, since generally considered as a bad practice to do updates on the spec of the controller. (Users with some special need will be able to still do it using the KubernetesClient or ResourceOperations.
  2. If other than the status is updated we might want to enforce optimistic locking in UpdateControl since there is a risk that it would override some changes on spec from third party.