Fix: AbstractCacheManager destroy Framework's executorService when shutdown

[Chenjp]

Introduce disposable resource register mechanism. Follows "who creates, who destroys" rule.

What is the purpose of the change

Protect framework-executor from being destroyed by AbstractCacheManager.

Brief changelog

Introduce disposable resource register mechanism, simplify disposable#destroy implementation.

Verifying this change

Checklist

• [x] Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
• [x] Each commit in the pull request should have a meaningful subject line and body.
• [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• [ ] Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
• [ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
• [ ] Add some description to dubbo-website project if you are requesting to add a feature.
• [ ] GitHub Actions works fine on your own branch.
• [ ] If this contribution is large, please follow the Software Donation Guide.

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
25.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[chickenlj]

The change itself in the refactoring patch is right. The "who creates, who destroys" design introduced is indeed impressive, but I think it's not so demanded in this scenario in which all operations are restricted inside one instance, it can be more useful when need to release or close resources across different components.

[Chenjp]

The change itself in the refactoring patch is right. The "who creates, who destroys" design introduced is indeed impressive, but I think it's not so demanded in this scenario in which all operations are restricted inside one instance, it can be more useful when need to release or close resources across different components.

@chickenlj Thank you for your comments. As mentioned, the change is right, is the PR ready to merged back?

[chickenlj]

The change itself in the refactoring patch is right. The "who creates, who destroys" design introduced is indeed impressive, but I think it's not so demanded in this scenario in which all operations are restricted inside one instance, it can be more useful when need to release or close resources across different components.

@chickenlj Thank you for your comments. As mentioned, the change is right, is the PR ready to merged back?

From the description of this PR, it fixes the following issue Protect framework-executor from being destroyed by AbstractCacheManager.. But what I see is only refactor, without any functionality changes, so I need to make sure if there's any bugfix or enhancement there before merging.

[Chenjp]

The change itself in the refactoring patch is right. The "who creates, who destroys" design introduced is indeed impressive, but I think it's not so demanded in this scenario in which all operations are restricted inside one instance, it can be more useful when need to release or close resources across different components.

@chickenlj Thank you for your comments. As mentioned, the change is right, is the PR ready to merged back?

From the description of this PR, it fixes the following issue Protect framework-executor from being destroyed by AbstractCacheManager.. But what I see is only refactor, without any functionality changes, so I need to make sure if there's any bugfix or enhancement there before merging.

Functional change: This PR is valuable only when CacheManager's lifecycle is different with Framework.