Endless Sync loop with ArgoCD Application CR triggered by including the operation field in ManifestWork's payload

[mikeshng]

Describe the bug
There is an issue with ManifestWork where an endless sync loop occurs when using the operation field in an ArgoCD Application CR deployed via a ManifestWork in a pull model setup.

To Reproduce
An Application CR like the following sitting idle:

kind: Application
spec: ...
status: ... NotSynced ...

To trigger a sync, you insert the operation field at the same level as the spec and status (so it's not part of the spec)

kind: Application
spec: ...
status: ...
operation:
  info:
  - name: Reason
    value: ApplicationSet RollingSync triggered a sync of this Application resource.
  initiatedBy:
    automated: true
    username: applicationset-controller
  retry: {}
  sync:
    syncOptions:
    - CreateNamespace=true

This will cause the ArgoCD Application controller to do the sync. When it's done with the sync, it removes the operation field so goes to

kind: Application
spec: ...
status: ... Synced ...

In the pull model, the Application is deployed to the managed cluster via ManifestWork.
If I modify that ManifestWork to contain

#manifestwork payload:  
  kind: Application
  spec: ...
  operation: ...

Then the managed cluster will receive the operation field. However, when the Application controller on the managed cluster completes the sync and removes the operation field, the work agent adds it back, causing an endless sync.

Expected behavior
We need a feature in ManifestWork to provide the update but then not keep enforcing it.

Environment ie: OCM version, Kubernetes version and provider:
v0.14.0 KinD cluster

Additional context
The OCM maintainers suggested maybe we can study how ArgoCD ignore difference work and implement something similar for the ManifestWork API: https://argo-cd.readthedocs.io/en/stable/user-guide/diffing/