Avoid duplicate connection attempts to active nodes before handshake completion

Rationale

Currently, the active connection task is executed every 3.6 seconds. During each execution, the task attempts to actively connect to all active nodes defined in the configuration file that have not yet successfully established a connection. The logic is illustrated as follows:

We have observed the following situation:

When the peer node experiences network latency or high system load, the P2P handshake process may be significantly delayed. As a result, multiple scheduled connection tasks may initiate several concurrent connection attempts to the same peer before the handshake completes. This causes the peer node to receive and process multiple handshake messages at nearly the same time, leading to unnecessary system resource consumption.
For example, node A initiates a connection to node B every 3.6 seconds, as shown in the following logs:

If node B is under heavy load and messages are queued, it might process multiple hello messages simultaneously at 17:05:56, as shown below:

Implementation

Add a handshake timeout mechanism for active nodes. If the handshake for a given node has not yet timed out, the system should not initiate a new connection request to the same node.

When initiating an active connection, the node address is cached for 120 seconds.
During the connection task, when selecting nodes (except those explicitly listed as active nodes), the system checks whether the node’s address already exists in the cache. If it does, it indicates that a connection attempt has already been made within the last 120 seconds, and the system will not initiate another one until the cache entry expires.

Proposed Optimization
Extend the same caching logic to active nodes:
Before initiating a connection to an active node, check whether its address exists in the cache. If it does, skip the connection attempt.

To ensure that disconnected active nodes can reconnect properly, remove their address from the cache when the connection is closed.

Start by tracing the active connection task and the existing 120-second address cache described in the issue, then inspect where connections close. Verify how active nodes are selected and how cache entries are removed. Done means repeated attempts are skipped during the handshake timeout while disconnected active nodes can reconnect after closure.