sync deployment replicas when it is controlled by hpa

[chaosi-zju]

What type of PR is this?

/kind feature

What this PR does / why we need it:

As for issue #4058, the previous implemention can not cover all cases, such as:

• member cluster hpa abnormal, we would sync a wrong replicas to resource template, just as described in The replicas of deployment is incorrectly when the related HPA is abnormal, #4109
• when user manually update spec.replicas in template, the modifition would be retained, and thus causing ready replias not equal to expect replicas when getting deployment (e.g: the user get deployment and see replicas ready/expect=2/2; then user manually update spec.replicas to 3; then user get deployment agagin and see replicas ready/expect=2/3; this displayment is not suitable for user to understand)
• In Duplicated schedule type, the spec.replicas in resource template has different meaning, it is not suitable to do this kind of replicas sync.
• ...

So, I introduced a deploymentReplicasSyncer to replace previous hpaReplicasSyncer:

• we intend to support replicas syncer only for deployment resources (hpa is not the way we recommend, while FederatedHPA is what we recommend. However, a small number of existing users have already used deployment in this way, and we have to support it; while other resources have not been used by users, we hope that they will directly use the recommended way.)
• replicas syncer indirectly by watching HPA resource takes a detour and hides a lot of unpredictable results. It is more suitable to directly watching Deployment resource. That is, replace spec.replicas with status.replicas if the two is not equal.

As for expected system behavior, it can be concluded as follows:

• If member cluster has deployment resource, and it is now controlled by hpa, change to template replicas will not sync to this member cluster
• If member cluster doesn't even have deployment resource, not to mention being controlled by the hpa, new added replicas can ben synced from template change.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

much appreciate everyone involved in this issue to participate in the review @XiShanYongYe-Chang @lxtywypc @chaunceyjiang

feel free to provide better resolution, however, your resolution should generally meet follow cases:

case 1) template (ready/expect=2/2), propagate to two cluster -> hpa scale all member cluster replicas to 4 -> template (ready/expect=4/4), even in the scenario of hpa abnormal、member cluster power down...

case 2) template (ready/expect=2/2), propagate to two cluster -> user update spec.replicas in template from 2 to 3 -> no matter what intermediate states is but should ensure that the final state is 2/2, and cannot be 2/3.

case 3) template (ready/expect=1/1), propagate to two cluster -> user update spec.replicas in template from 1 to 2 -> final state should be 2/2, that means one member cluster previously doesn't have deployment, now it has one replica.

Does this PR introduce a user-facing change?:

Introduced `deploymentReplicasSyncer` controller which syncs Deployment's replicas from the member cluster to the control plane, while previous `hpaReplicasSyncer` been replaced.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 51.68%. Comparing base (9ccc8be) to head (58ada63).
Report is 6 commits behind head on master.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4707      +/-   ##
==========================================
+ Coverage   51.41%   51.68%   +0.27%     
==========================================
  Files         250      247       -3     
  Lines       24979    24777     -202     
==========================================
- Hits        12842    12807      -35     
+ Misses      11431    11264     -167     
  Partials      706      706              

Flag	Coverage Δ
unittests	51.68% <ø> (+0.27%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[RainbowMango]

This feature needs a release notes.

/assign @XiShanYongYe-Chang

[XiShanYongYe-Chang]

/lgtm

[RainbowMango]

/lgtm
/approve

[karmada-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: RainbowMango

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [RainbowMango]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment