Fix cached thread pool cannot recycle idle core threads (#8342)

[ABin-Huang]

What is the purpose of the change?

Fix #8342.

When threadpool=cached is configured with an explicit positive corethreads (e.g. corethreads=2, threads=5, alive=15000), idle core threads are never reclaimed, so the pool can never shrink below corePoolSize, even when every thread stays idle far longer than the configured keep-alive (alive). This contradicts the contract documented on CachedThreadPool — "Thread will be recycled after idle for one minute" — and the behavior of java.util.concurrent.Executors#newCachedThreadPool() that it is modeled on.

Root cause

CachedThreadPool#getExecutor builds a JDK ThreadPoolExecutor but never calls allowCoreThreadTimeOut(true). By default a ThreadPoolExecutor does not time out core threads while they wait on the queue, so with corethreads > 0 those core threads stay alive forever.

Fix

Call executor.allowCoreThreadTimeOut(true) for the cached pool so idle core threads are also reclaimed once they have been idle for alive.

• The default cached pool uses corethreads = 0, so the default behavior is unchanged.
• fixed / limited / eager pools are intentionally left untouched and keep their current (non-shrinking) semantics.

Tests

• Added CachedThreadPoolTest#idleCoreThreadsShouldBeRecycledAfterKeepAlive: grow the pool to maximumPoolSize, release all tasks and assert the pool shrinks back to 0 after keep-alive. The test fails (times out) before this fix and passes after.
• Added an allowsCoreThreadTimeOut() assertion to getExecutor1.
• The whole org.apache.dubbo.common.threadpool test package passes locally (41 tests, 0 failures/errors); spotless formatting applied.

Checklist

• Make sure there is a GitHub_issue field for the change. (threadpool=cached can not recycle idle thread #8342)
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Write necessary unit-test to verify your logic correction. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
• Make sure gitHub actions can pass. Why the workflow is failing and how to fix it?

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 60.91%. Comparing base (dab47b7) to head (edd99be).

Additional details and impacted files

@@             Coverage Diff              @@
##                3.3   #16450      +/-   ##
============================================
- Coverage     60.91%   60.91%   -0.01%     
- Complexity       15    11762   +11747     
============================================
  Files          1953     1953              
  Lines         89271    89273       +2     
  Branches      13473    13473              
============================================
- Hits          54383    54381       -2     
- Misses        29309    29315       +6     
+ Partials       5579     5577       -2     

Flag	Coverage Δ
integration-tests-java21	32.14% <100.00%> (+<0.01%)	⬆️
integration-tests-java8	32.21% <100.00%> (-0.01%)	⬇️
samples-tests-java21	32.08% <100.00%> (-0.08%)	⬇️
samples-tests-java8	29.82% <100.00%> (-0.01%)	⬇️
unit-tests-java11	59.15% <100.00%> (-0.01%)	⬇️
unit-tests-java17	58.63% <100.00%> (-0.03%)	⬇️
unit-tests-java21	58.63% <100.00%> (-0.02%)	⬇️
unit-tests-java25	58.60% <100.00%> (-0.01%)	⬇️
unit-tests-java8	59.21% <100.00%> (+0.03%)	⬆️

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

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.