fix: throw clear exception when request parameter is not Serializable

[joaohmalves]

Previously, passing a non-Serializable parameter to a Dubbo service resulted in a confusing error message. Now a clear IOException with the class name and 'must implement java.io.Serializable' is thrown at encode time in both request and response paths.

Fixes #16293

What is the purpose of the change?

This PR fixes a misleading error message when calling a Dubbo service
with a parameter or return value that does not implement
java.io.Serializable.

Previously, the error was buried inside internal serialization layers
and did not clearly indicate the root cause, making it hard to diagnose.
Now a clear IOException containing the class name and
must implement java.io.Serializable is thrown at encode time in both
request and response paths.

What is changed?

• DubboCodec.encodeRequestData(): wraps writeObject() in a
  try/catch that intercepts the internal IllegalArgumentException and
  rethrows a clear IOException with the offending class name.
• DubboCodec.encodeResponseData(): same treatment for the response path.
• DubboProtocolTest: re-enabled testNonSerializedParameter and
  testReturnNonSerialized which were previously @Disabled because
  the expected behavior was not implemented.

Verifying this change

All tests in dubbo-rpc-dubbo module pass locally, including the
two previously disabled tests that now validate the correct behavior.

Checklist

• Make sure there is a GitHub_issue field for the change.
• 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

❌ Patch coverage is 63.15789% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 60.75%. Comparing base (abf4e98) to head (6605aa2).
⚠️ Report is 1 commits behind head on 3.3.

Files with missing lines	Patch %	Lines
...rg/apache/dubbo/rpc/protocol/dubbo/DubboCodec.java	63.15%	1 Missing and 6 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##                3.3   #16298      +/-   ##
============================================
- Coverage     60.78%   60.75%   -0.03%     
+ Complexity    11766    11751      -15     
============================================
  Files          1953     1953              
  Lines         89186    89203      +17     
  Branches      13454    13462       +8     
============================================
- Hits          54208    54196      -12     
- Misses        29411    29433      +22     
- Partials       5567     5574       +7     

Flag	Coverage Δ
integration-tests-java21	32.18% <52.63%> (+0.05%)	⬆️
integration-tests-java8	?
samples-tests-java21	32.21% <26.31%> (+0.03%)	⬆️
samples-tests-java8	29.83% <26.31%> (+0.07%)	⬆️
unit-tests-java11	59.01% <47.36%> (-0.04%)	⬇️
unit-tests-java17	58.49% <47.36%> (+0.01%)	⬆️
unit-tests-java21	58.49% <47.36%> (-0.03%)	⬇️
unit-tests-java25	58.46% <47.36%> (-0.01%)	⬇️
unit-tests-java8	59.05% <47.36%> (+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.

[RainYuY]

Have you checked the situation of the issue?I couldn't reproduce. Moreover, it seems that such changes risk swallowing non-Serializer exceptions?

[joaohmalves]

After checking a bit further, I was unable to reproduce the exact NPE from the stack trace (GroupServiceKeyCache.getServiceKey).
What I found instead is that Dubbo already detects the non-Serializable class in DefaultSerializeClassChecker and logs an ERROR, but does not propagate a clear exception.

Also as you pointed out this fix does risks swallowing unrelated exceptions so I would like to work on it a bit more.

As this is my first contribution to this project, would it make sense for me to go back to the issue and ask the reporter for more details on how to reproduce the exact stack trace before reworking this PR?