[Bug] all channels of the EventLoop delay time

### Pre-check

- [X] I am sure that all the content I provide is in English.

### Search before asking

- [X] I had searched in the [issues](https://github.com/apache/dubbo/issues?q=is%3Aissue) and found no similar issues.

### Apache Dubbo Component

Java SDK (apache/dubbo)

### Dubbo Version

dubbo 3.2.12

### Steps to reproduce this issue

```
org.apache.dubbo.remoting.transport.netty4.NettyConnectionClient.ConnectionListener#operationComplete

final EventLoop loop = future.channel().eventLoop();
loop.schedule(
() -> {
try {
connectionClient.doConnect();
} catch (RemotingException e) {
LOGGER.error(
TRANSPORT_FAILED_RECONNECT,
"",
"",
"Failed to connect to server: " + getConnectAddress());
}
},
1L,
TimeUnit.SECONDS);

```
connectionClient Always fails to connect, default connection wait time is 3 seconds. This will occupy the EventLoop CPU from time to time, and indirectly affect the communication of other registered EventLoop channels. Sometimes there may be a request timeout.
1. The server receives the request with a delay.Timely
2. server execution is short, client still sometimes timeout.

### What you expected to happen

1. Simply handle the connection and wait only for a shorter period of time. For example, 500ms, this way, has been provided. The dead loop body occupies the EventLoop for a long time.

2. It is recommended to add a user thread instead of the EventLoop

### Anything else

_No response_

### Are you willing to submit a pull request to fix on your own?

- [X] Yes I am willing to submit a pull request on my own!

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)

Start at org.apache.dubbo.remoting.transport.netty4.NettyConnectionClient.ConnectionListener#operationComplete and inspect how failed connections schedule reconnect attempts on the EventLoop. Reproduce the failure with the 3-second connection wait and observe EventLoop impact and request timeouts. Done means reconnect handling no longer delays other channels while preserving timely connection retries.

Written by the indexing model from the issue text.