Cloning of secondary resource when getting it from InformerEventSource cache #2351

Currently, the resource is cloned when read from the cache of an informer. The reason behind this is, it happened in the past that that someone modified the secondary, and therefore in the next reconciliation (even related to other primary resources) the changed value was returned from the cache. However, if the getSecondaryResource is called multiple times, it might cause a significant overhead.

See issue: https://issues.apache.org/jira/browse/FLINK-34726

Note for the primary: we always clone the primary resource, where it is more justified, since when updating the resource with UpdateControl the changes were always made on the primary. However, this is not true with SSA anymore, see:
#1931

For SSA we could always say that a fresh resource should be created always for the operations (now it's kinda not needed for the status patch, since while it sends the whole resource, only the status sub-resource is handled by k8s API, so it kinda works also in the old way)