Description of problem:

When using a ResourceBundle to apply a ManifestWork with the Server Side Apply (SSA) strategy, the status of the applied ManifestWork will be updated frequently.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

1. Create a kube resource.
2. Add the created kube resource to a ManifestWork's workloads
3. Add the ManifestWork to a ResourceBundle's workloads
4. Set the  ResourceBundle's update strategy to SSA
5. Create the ResourceBundle with maestro ManifestWork client

Actual results:

When the ManifestWork contained in a ResourceBundle is applied to a management cluster, the generation of the ManifestWork will continually increase, even if there are no changes to the ManifestWork,  the ResourceBundle's status still updated continually.

Expected results:

If the ManifestWork is no change, the ResourceBundle's status should not be updated.

Additional info:

This issue only happens when ResourceBundle using SSA strategy and ResourceBundle workloads are ManifestWorks

The cause of this problem

When adding a kube resource to a ManifestWork's workloads, the kube resource's `creationTimestamp` will be presented in the ManifestWork's workloads, e.g.

  kind: ManifestWork
  metadata:
    name: wrapped-work
  manifests:
  - kind: Namespace
    metadata:
      name: test-namespace
      creationTimestamp: null  <---- this is not expected
      labels:
        test: test
... 

When using SSA stratage to apply the wrapped ManifestWork (`wrapped-work`), the kube-apiserver received ManifestWork will be like

  kind: ManifestWork
  metadata:
    name: wrapped-work
  manifests:
  - kind: Namespace
    metadata:
      name: test-namespace
      labels:
        test: test

so the kube-apiserver SSA thinks the ManifestWork is changed, it updates the ManifestWork and increase the generation of the ManifestWork.

Here is a related issue (https://github.com/kubernetes/kubernetes/issues/67610) in the k8s community.

Here is a possible solution:

• If a ResourceBundle's workloads are ManifestWorks, we should use the Update strategy for this ResourceBundle 
• If a ResourceBundle's workloads are not ManifestWork, we can still use the SSA strategy for the ResourceBundle

For our current case:

1. We used the SSA strategy to avoid the ManagedCluster conflicting problem, because we did not use ManifestWork to  wrap the ManagedCluster in ResourceBundle, we can still keep the SSA strategy in its ResourceBundle
2. For those resources that are wrapped with a ManifestWork, if we need to avoid conflicting, we can set the SSA strategy in their wrapped ManifestWork, not in the ResourceBundle