[feature] When CloneSet volumeClaimTemplates changed, Pod must ReCreate update

[ABNER-1]

Ⅰ. Describe what this PR does

Implemented "When volumeClaimTemplates are modified, the pod must ReCreate update"

1. If both the volumeClaimTemplates spec and the image are modified -> recreate.
2. If only the volumeClaimTemplates spec is modified -> no changes util next template spec changes
3. next modification of the image or other configurations -> recreate update
4. To prevent unnecessary pod recreate update, the initial upgrade of CloneSets that previously utilized the volumeClaimTemplates feature will bypass the comparison of historical revisions lacking hash values after the Kruise upgrade.
   • Abandoned the implementation of calculating the hash from pod volumes and existing PVCs: some PVCs have inherent fields that do not exist in volumeClaimTemplates, leading to calculated hash values that are inconsistent with the hash values calculated based on volumeClaimTemplates.

Corner case in 4

1. Before the Kruise upgrade, CloneSet with image 1 and vcTemplates size 1Mi.
2. After the Kruise upgrade, an update was applied to use image 2 and vcTemplate size 10Mi. However, due to the absence of hash values for historical revisions, this update will not trigger a recreation, and the actual pod will be like image 2 and vcTemplate size 1Mi. The revision will incorrectly record the hash value for the 10Mi size. Future updates in this situation need to be cautious.
3. It is recommended not to modify the vcTemplate during the first update after the Kruise upgrade.

detail in #1536

Ⅱ. Does this pull request fix one issue?

detail in #1536
fixes #1536

Ⅲ. Describe how to verify it

detail case in #1536

Main test cases:

1. image 1, vctemplate size of 1MB.
2. Image 2, vcTemplate size of 1MB.
3. Image 3, vcTemplate size of 1MB. (in function testUpdate)
4. Image 4, vcTemplate size of 10MB => recreate.
5. Image 2, vcTemplate size of 10MB => (expected in-place upgrade)
   --- Although the history revision hash is consistent, the vct hash is not, update history revision id and hash value
6. Image 4, vcTemplate size of 10MB => in-place upgrade --- Update history revision.
7. Image 4, vcTemplate size of 100MB => (temporarily unchanged) --- Do not generate a new revision.
8. Image 5, vcTemplate size of 100MB => recreate.

Ⅳ. Special notes for reviews

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 49.28%. Comparing base (0d0031a) to head (d5e6703).
Report is 25 commits behind head on master.

❗ Current head d5e6703 differs from pull request most recent head 15fab30. Consider uploading reports for the commit 15fab30 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1561      +/-   ##
==========================================
+ Coverage   47.91%   49.28%   +1.36%     
==========================================
  Files         162      164       +2     
  Lines       23491    18811    -4680     
==========================================
- Hits        11256     9271    -1985     
+ Misses      11014     8318    -2696     
- Partials     1221     1222       +1     

Flag	Coverage Δ
unittests	49.28% <100.00%> (+1.36%)	⬆️

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.

[ABNER-1]

/retest @kruise-bot

[kruise-bot]

@ABNER-1: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/retest

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[ABNER-1]

I will add a feature gate about this feature, and set default value to false.

[ABNER-1]

squash commits and retest

[furykerry]

/lgtm

[zmberg]

/approve

[kruise-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: zmberg

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 [zmberg]

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

[HURUIZHE]

I would like to ask a question, since the VolumeClaimTemplate is not stored in the ControllerRevision of the controller, how can I roll it back when I modified VolumeClaimTemplate in cloneSet? And how do I create the correct old instance when I publish @ABNER-1