optimize : skip sending some request if client-version is v0

[Bughue]

• I have registered the PR changes.

Ⅰ. Describe what this PR did

1. 新增了客户端版本+msgType来判断是否跳过的逻辑
2. 这个功能在sendAsync和sendSync都加上了，保证代码逻辑的一致性，但sendSync的“if”是不会进的。
3. sendSync的时候会返回一个VersionNotSupportMessage。目前来说TC使用sendSync的逻辑不会做这种判断，后续如果有skip的情况就需要在接收的时候先判断类型，而不是直接强转。
4. 在NettyClientChannelManager中为channel注册版本号

---

1. Added client version + msgType to determine whether to skip the logic.
2. this feature is added to both sendAsync and sendSync to ensure the consistency of code logic, but the “if” of sendSync will not be entered.
3. sendSync will return a VersionNotSupportMessage. at present, TC use sendSync logic will not do this kind of judgment, and then if there is a skip case you need to judge the type of the first time you receive, rather than directly force the transfer.
4. Register the version number for the channel in the NettyClientChannelManager

Translated with DeepL.com (free version)

Ⅱ. Does this pull request fix one issue?

fixes #6999

Ⅲ. Why don't you add test cases (unit test/integration test)?

Ⅳ. Describe how to verify it

Ⅴ. Special notes for reviews

[codecov]

Codecov Report

Attention: Patch coverage is 14.81481% with 23 lines in your changes missing coverage. Please review.

Project coverage is 52.73%. Comparing base (6cdb847) to head (1cde9d3).

Files with missing lines	Patch %	Lines
...va/org/apache/seata/core/rpc/MsgVersionHelper.java	30.76%	7 Missing and 2 partials ⚠️
...he/seata/core/rpc/netty/AbstractNettyRemoting.java	0.00%	6 Missing and 2 partials ⚠️
.../seata/core/protocol/VersionNotSupportMessage.java	0.00%	2 Missing ⚠️
...n/java/org/apache/seata/core/protocol/Version.java	0.00%	1 Missing ⚠️
...eata/core/rpc/netty/NettyClientChannelManager.java	0.00%	1 Missing ⚠️
...he/seata/core/rpc/netty/RmNettyRemotingClient.java	0.00%	1 Missing ⚠️
...he/seata/core/rpc/netty/TmNettyRemotingClient.java	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##                2.x    #6998      +/-   ##
============================================
- Coverage     52.75%   52.73%   -0.02%     
- Complexity     6635     6642       +7     
============================================
  Files          1126     1128       +2     
  Lines         40122    40147      +25     
  Branches       4700     4707       +7     
============================================
+ Hits          21165    21171       +6     
- Misses        16944    16961      +17     
- Partials       2013     2015       +2     

Files with missing lines	Coverage Δ
...n/java/org/apache/seata/core/protocol/Version.java	69.04% <0.00%> (+0.75%)	⬆️
...eata/core/rpc/netty/NettyClientChannelManager.java	59.49% <0.00%> (-0.38%)	⬇️
...he/seata/core/rpc/netty/RmNettyRemotingClient.java	52.59% <0.00%> (ø)
...he/seata/core/rpc/netty/TmNettyRemotingClient.java	72.54% <0.00%> (ø)
.../seata/core/protocol/VersionNotSupportMessage.java	0.00% <0.00%> (ø)
...he/seata/core/rpc/netty/AbstractNettyRemoting.java	49.38% <0.00%> (-2.57%)	⬇️
...va/org/apache/seata/core/rpc/MsgVersionHelper.java	30.76% <30.76%> (ø)

... and 4 files with indirect coverage changes

[funky-eyes]

看起来没有使用到它的地方，后续将有何作用？
It seems that it is not being used anywhere. What will its role be in the future?

[Bughue]

看起来没有使用到它的地方，后续将有何作用？ It seems that it is not being used anywhere. What will its role be in the future?

比如以后的版本里如果要sync发送某个全新的request类，旧版本无法识别，在remote通信这层会返回VersionNotSupportMessage，发送者判断到返回类型是这个后做忽略处理或者抛出异常

For example, if you want to send a sync to a new request class in a future version that is not recognized by the old version, the versionNotSupportMessage will be returned at the remote communication level, and the sender will either ignore the return type or throw an exception.