[TubeMQ] Adjust FATAL type error return content, without carrying class name

[gosonzhang]

Description

There is indeed a problem [1] with this RPC interaction agreement: the server-side transparently transmits the exception class to the caller. In any case, the callee should return a clear error to the caller. If an unknown exception is encountered, the detailed information should be retained locally, rather than being transparently transmitted to the calling layer.

In the case where the accessed party is a malicious node injecting exceptions, there is a risk of introduction based on the aforementioned issue. This risk exists, but it is not urgent

1. https://github.com/apache/inlong/blob/master/inlong-tubemq/tubemq- core/src/main/java/org/apache/inlong/tubemq/corerpc/netty/NettyClient.java#L349

InLong Component

InLong TubeMQ

Are you willing to submit PR?

• [X] Yes, I am willing to submit a PR!

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity.

[gosonzhang]

I'll fix the issue, thans!

[gosonzhang]

Based on the premise that we will not access untrusted external services through an SDK, we can make a simple modification to this problem for now: in the unwrapException function, only construct objects for clazz that belong to the Throwable class or its subclasses, to avoid Remote Code Execution (RCE) issues.

In the future, we can consider adjusting the interaction protocol between the SDK and the Server to avoid object construction on the SDK side.