delete operation-type when all IDs' operate finished

[ColdsteelRail]

1. Does this PR affect any open issues?(Y/N) and add issue references (e.g. "fix #123", "re #123".):

• N
• Y

2. What is the scope of this PR (e.g. component or file name):

3. Provide a description of the PR(e.g. more details, effects, motivations or doc link):

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Other

4. Are there any breaking changes?(Y/N) and describe the breaking changes(e.g. more details, motivations or doc link):

• N
• Y

5. Are there test cases for these changes?(Y/N) select and add more details, references or doc links:

• Unit test
• Integration test
• Benchmark (add benchmark stats below)
• Manual test (add detailed scripts or steps below)
• Other

6. Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

None

[shaofan-hs]

Add a unit test for mutating webhook?

[shaofan-hs]

Labels
->
labels

[ColdsteelRail]

在 lifecycle 的设计中，允许多个 ID（controller） 运维同一个对象，并且让这些 ID 经历同 1 次摘挂流，但存在一个问题：假设 ID-A 和 ID-B 运维同一个 Pod，率先执行完 Operation 的 ID-A 会在挂流前等待 ID-B，此时 ID-A 的 {id: type} 标签被提前删除，但后续阶段还需用到 {id: type} 标签，导致 ID-A 被死锁在 operation 阶段。该 PR 修复了这个问题，当且仅当所有 ID 进入挂流阶段时，才删除 {id: type} 信息

[ColdsteelRail]

In the design of the lifecycle, it is allowed for multiple IDs (controllers) to manage the same object and go through the attachment-detachment process together. However, there exists a problem: suppose ID-A and ID-B are managing the same Pod. If ID-A finishes its operation first, it will wait for ID-B before the detachment phase. At this point, the {id: type} label of ID-A is prematurely deleted, but this label is still needed in later stages, causing ID-A to be deadlocked in the operation phase. This PR fixes the issue by ensuring that the {id: type} information is only deleted when all IDs have entered the detachment phase.