[TRACKING ISSUE] Prevent client ending up with two addresses to same node when node is behind a private network

The tracking issue for the Java side PR.

**Prevent client ending up with two addresses to same node when node is behind a private network**

See https://github.com/hazelcast/hazelcast/pull/17844 for details.

---

Background :

getOrConnect method tries to open a connection to an
address only once. It should never open a second connection
to a member. To achieve that we are using the remote address
of a connection as the source of truth. The remote address is the
one in the member list for members.

If the member is using private-addresses on a closed network,
the client can not use that address on its config to connect that member.
So we have two addresses to define a single member on the client-side.

How bug happens:

When a client is already connected to members, it could be the case that
all connections are dropped temporarily. In that case, we trigger
`doConnectToCandidateCluster` logic. It connects to a random address
provided in the config. This one can use `public address` of the member.

In the meantime, we have a periodic task `ConnectToAllClusterMembersTask`
that tries to connect to all members in the latest known memberlist.
This one uses the remote address which is the `private address`

Both of them uses `getOrConnect` and `doConnectToCandidateCluster`
can open a second connection while a first one is already there.
Note that some of our other services rely on single connection per member
logic.

How to fix:
1. `uuid` will be used as the source of truth.
This means what we can not know the uuid of a connection before opening
a connection first. We will allow opening connections parallelly from
`doConnectToCandidateCluster` path. As soon as a response returned from the
server(with uuid), we check if a connection is already there and close
the new connection before putting it in `activeConnection`.

Periodic `ConnectToAllClusterMembersTask` will not try to connect
an already connected member.And it will use `uuid` to decide that.

2. These two paths will not use the same method `getOrConnect` to simplify
the logic. One will be based on the address and the other only uuid to
make the intent clear.

Test:
I could not write a unit test because this requires an inaccessible
private network behind a public address.