Fix Hessian2 writeReplace Serializable check bypass

[yuzhiyang1]

What is the purpose of the change?

Fixes #16287.

Hessian2SerializerFactory currently enforces Dubbo's serialization class policy from getDefaultSerializer(). However, hessian-lite resolves classes with writeReplace() before it reaches getDefaultSerializer(), so non-Serializable classes with writeReplace() can bypass the sender-side Serializable check.

This change enforces the same class policy in getSerializer(Class) for replacement-capable classes before delegating to hessian-lite, while keeping the existing default serializer/deserializer checks shared through one helper.

Brief changelog

• Enforce Dubbo's serialization class policy for Hessian2 classes that define writeReplace().
• Keep existing getDefaultSerializer() and getDefaultDeserializer() checks by sharing the same checkClass() helper.
• Add regression coverage for:
  • non-Serializable class whose writeReplace() returns itself;
  • Serializable class whose writeReplace() returns a non-Serializable replacement with its own writeReplace();
  • valid Serializable replacement path.

Verifying this change

• git diff --check
• mvn -am -pl dubbo-serialization/dubbo-serialization-hessian2 -Dtest=Hessian2SerializationTest -Dsurefire.failIfNoSpecifiedTests=false -Dcheckstyle.skip=true -Drat.skip=true test

Checklist

• Make sure there is a GitHub issue field for the change. (Classes with writeReplace() bypass Hessian2 Serializable security check #16287)
• 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.
• Make sure GitHub Actions can pass.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 60.79%. Comparing base (ee9c190) to head (913a538).

Additional details and impacted files

@@             Coverage Diff              @@
##                3.3   #16307      +/-   ##
============================================
+ Coverage     60.77%   60.79%   +0.01%     
- Complexity    11768    11776       +8     
============================================
  Files          1953     1953              
  Lines         89196    89198       +2     
  Branches      13457    13457              
============================================
+ Hits          54212    54231      +19     
+ Misses        29418    29403      -15     
+ Partials       5566     5564       -2     

Flag	Coverage Δ
integration-tests-java21	32.12% <70.00%> (+<0.01%)	⬆️
integration-tests-java8	32.23% <70.00%> (-0.02%)	⬇️
samples-tests-java21	32.19% <90.00%> (+0.01%)	⬆️
samples-tests-java8	29.77% <70.00%> (-0.09%)	⬇️
unit-tests-java11	59.01% <100.00%> (-0.04%)	⬇️
unit-tests-java17	58.53% <90.00%> (+0.02%)	⬆️
unit-tests-java21	58.54% <90.00%> (+0.04%)	⬆️
unit-tests-java25	58.46% <90.00%> (+0.05%)	⬆️
unit-tests-java8	59.04% <100.00%> (-0.02%)	⬇️

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.

🚀 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.

[yuzhiyang1]

The CI failure was caused by the previous follow-up enforcing the full strict allow-list check for classes with writeReplace(). That also rejected JDK immutable collection implementations such as java.util.ImmutableCollections in Java 21 samples. I narrowed the writeReplace path to enforce only the Serializable requirement, which is the bypass covered by this issue, and added a regression test for JDK immutable lists under STRICT mode. The latest Build and Test run is now green.

[LI123456mo]

LGTM