Fix forkingclusterinvoker npe

[codeimport]

What is the purpose of the change

fix #9582
When the cluster uses the forking mode and the provider side all times out ,consumer side will npe

Brief changelog

org.apache.dubbo.rpc.cluster.support.ForkingClusterInvoker
org.apache.dubbo.rpc.cluster.support.ForkingClusterInvokerTest

Verifying this change

Checklist

• Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
• Each commit in the pull request should have a meaningful subject line and body.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
• Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
• Add some description to dubbo-website project if you are requesting to add a feature.
• GitHub Actions works fine on your own branch.
• If this contribution is large, please follow the Software Donation Guide.

When the cluster uses the forking mode and the provider side all times out, the poll method used in forkingClusterInvoker will time out earlier than the provider side, so it will get null from the queue and throw NPE in the subsequent process. The poll method here should not set the timeout time, but wait for the provider to timeout. When the provider times out, the poll method will correctly obtain an RpcException

[codecov-commenter]

Codecov Report

Merging #9612 (ec78ca1) into 3.0 (b8a1398) will increase coverage by 0.08%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##                3.0    #9612      +/-   ##
============================================
+ Coverage     65.66%   65.75%   +0.08%     
  Complexity      297      297              
============================================
  Files          1189     1189              
  Lines         51824    51823       -1     
  Branches       7843     7843              
============================================
+ Hits          34032    34077      +45     
+ Misses        14117    14076      -41     
+ Partials       3675     3670       -5     

Impacted Files	Coverage Δ
...bbo/rpc/cluster/support/ForkingClusterInvoker.java	86.84% <100.00%> (-0.34%)	⬇️
...ting/zookeeper/curator/CuratorZookeeperClient.java	68.75% <0.00%> (-1.93%)	⬇️
...pache/dubbo/registry/support/AbstractRegistry.java	75.35% <0.00%> (-1.06%)	⬇️
...rg/apache/dubbo/common/timer/HashedWheelTimer.java	85.56% <0.00%> (+0.34%)	⬆️
.../dubbo/registry/integration/RegistryDirectory.java	49.24% <0.00%> (+0.37%)	⬆️
...ubbo/registry/client/AbstractServiceDiscovery.java	89.56% <0.00%> (+1.73%)	⬆️
...exchange/support/header/HeaderExchangeHandler.java	62.83% <0.00%> (+1.76%)	⬆️
...ing/zookeeper/curator/Curator5ZookeeperClient.java	69.56% <0.00%> (+1.93%)	⬆️
.../registry/zookeeper/ZookeeperServiceDiscovery.java	84.12% <0.00%> (+3.17%)	⬆️
...apache/dubbo/rpc/protocol/dubbo/DubboProtocol.java	64.80% <0.00%> (+3.28%)	⬆️
... and 6 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b8a1398...ec78ca1. Read the comment docs.

[wangchengming666]

LGTM

[juzi214032]

I don't think it's reasonable to make the queue wait indefinitely, which may generate some unknown exceptions, and a reasonable way would be to reverse the relevant exception message when the ret is empty

[AlbumenJ]

Agree with @juzi214032

[chickenlj]

solved by #9613