Use the control connection address for the control host in the cluster topology metadata seen by the proxy

[alicel]

When the proxy connects to Origin and Target, it builds a view of the metadata of each using the data from their system.local and system.peers tables.

These queries are run on the control host after the control connection is established. While the RPC address of the peers is always available in the system.peers table, early C* 2.1 versions did not contain the RPC address of the local node in system.local.

At the moment we rely on the RPC address from system.local to populate the address of the control host when we create the topology information in the proxy. This means that, in case of clusters on C* versions older than 2.1.6, the address of the control host in the proxy’s topology view is going to be null. Apart from being generally incorrect, this causes a practical issue if a proxy instance selects its control host as one of its assigned hosts, as it will be unable to connect to this malformed assigned host.

To fix this for all versions, we should be using the control host address (which is always known, as we are connecting to it in the first place) when populating the control host metadata in the cluster topology, instead of relying on the address in system.local. This is in line with what the Java driver does.

For this change to work efficiently, we must ensure that we always use hostID as the node identifier and consider the IP address just like a regular piece of metadata about the node.

┆Issue is synchronized with this Jira Task by Unito
┆Components: Proxy
┆Issue Number: ZDM-511

[joao-r-reis]

Also worth noting that this is useful for deployments that have specific network conditions (e.g. NAT) where the contact point address does not match the one on system.local although this is probably only useful for single node deployments because it would result in the proxy being able to connect to the local host only.