Implement bonus group score calc to assign replicas evenly

[ipsum-0320]

What type of PR is this? /kind feature

What this PR does / why we need it: Optimize the score calculation method to better measure the pros and cons of the group. This PR implements bonus group score calc to assign replicas evenly.

Which issue(s) this PR fixes: Part of #4805

Special notes for your reviewer: @whitewindmills

Does this PR introduce a user-facing change?:

`karmada-scheduler`: implement group score calculation instead of take the highest score of clusters

[codecov-commenter]

:warning: Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 94.11765% with 1 line in your changes missing coverage. Please review.

Project coverage is 41.64%. Comparing base (ff6075c) to head (9e349e6).

Files with missing lines	Patch %	Lines
.../scheduler/core/spreadconstraint/group_clusters.go	94.11%	1 Missing :warning:

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

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5622      +/-   ##
==========================================
- Coverage   41.66%   41.64%   -0.03%     
==========================================
  Files         653      653              
  Lines       55518    55533      +15     
==========================================
- Hits        23132    23127       -5     
- Misses      30885    30908      +23     
+ Partials     1501     1498       -3     

Flag	Coverage Δ
unittests	41.64% <94.11%> (-0.03%)	:arrow_down:

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[whitewindmills]

wait for https://github.com/karmada-io/karmada/pull/5621 /hold

[RainbowMango]

wait for #5621 /hold

Let's get back on this as #5621 has been merged.

[ipsum-0320]

i will resolve the conflicts.

[ipsum-0320]

now, i have do something for this PR. i need you guys on resolving the merge conflict. @whitewindmills @RainbowMango

[whitewindmills]

/unhold

[RainbowMango]

now, i have do something for this PR. i need you guys on resolving the merge conflict. @whitewindmills @RainbowMango

I can't figure out the intention of this PR. And, do you mean you don't know how to resolve the conflicts? Basically you can do that as follows:

1. checkout to your feature branch by `git checkout Implement-group-score-calc-bonus`
2. reset the latest commit on you feature branch by `git reset HEAD~1`
3. stash your commit to cache: `git stash`
4. fetch the upstream and rebase
  * `git fetch upstream`
  * `git rebase upstream/master`
5. restore your commit: `git stash pop` 
  * Note: you can skip this step too if you prefer to write the code from the start. But if you do, you will see the conflicts by checking the status `git status`
 ...

[ipsum-0320]

now, i have do something for this PR. i need you guys on resolving the merge conflict. @whitewindmills @RainbowMango

I can't figure out the intention of this PR. And, do you mean you don't know how to resolve the conflicts? Basically you can do that as follows:

1. checkout to your feature branch by `git checkout Implement-group-score-calc-bonus`
2. reset the latest commit on you feature branch by `git reset HEAD~1`
3. stash your commit to cache: `git stash`
4. fetch the upstream and rebase
  * `git fetch upstream`
  * `git rebase upstream/master`
5. restore your commit: `git stash pop` 
  * Note: you can skip this step too if you prefer to write the code from the start. But if you do, you will see the conflicts by checking the status `git status`
 ...

I've resolved the conflicts, so we can consider merging now. Additionally, I'll clarify the purpose of this PR:

As shown in the code, PR #5621 actually represents the GroupScore algorithm when the replica allocation strategy is set to Divided. In contrast, this PR (#5622) provides the GroupScore algorithm for the Duplicate replica allocation strategy. It stands to reason that with Duplicate, the GroupScore algorithm should differ due to the distinct behavior of replica allocation. The GroupScore algorithm I designed works as follows: in a Group, the more clusters that meet the Replica requirement for available copies, the higher the Group Score. If the number of clusters meeting the Replica requirement is the same, then the Group with a higher average cluster score will have a higher Group Score. @whitewindmills @RainbowMango

[ipsum-0320]

I've solved these problems. @whitewindmills

[whitewindmills]

/approve /assign @RainbowMango

[karmada-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: RainbowMango, whitewindmills

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:

• ~~pkg/scheduler/OWNERS~~ [RainbowMango,whitewindmills]

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