IPv6 handling should know to handle leading Zeros

[roydahan]

The longevity-3h-ipv6 failed in ClusterHealthValidation when trying to compare the nodes in "nodetool status" vs gossip.
(https://argus.scylladb.com/test/c7dc9095-8ed2-4eb2-9467-d1b50a250012/runs?additionalRuns[]=1de0fc08-3a5c-4b94-92e1-277b149fd8d4)

2a05:d018:12e3:f000:60f6:0547:2b7c:18ba
vs
2a05:d018:12e3:f000:60f6:547:2b7c:18ba

The root cause is probably the updates of java libraries that supports removing leading zeros.
(https://guava.dev/releases/snapshot/api/docs/com/google/common/net/InetAddresses.html#toAddrString-java.net.InetAddress-)

According to the RFC it's a valid representation of IPv6, so I think SCT should support it when comparing IPv6 addresses.

For the record, here are the errors we get in ClusterHealthValidator:

2023-12-28 06:26:01.397: (ClusterHealthValidatorEvent Severity.ERROR) period_type=one-time event_id=882d2230-f894-46a6-a56b-ffca1687ab5a: type=NodeSchemaVersion node=longevity-10gb-3h-2024-1-db-node-1de0fc08-2 error=Current node Node longevity-10gb-3h-2024-1-db-node-1de0fc08-2 [3.250.13.143 | 10.4.0.45 | 2a05:d018:12e3:f000:3eb0:1b2:d2e9:9d3d] (seed: True). Nodes 2a05:d018:12e3:f000:60f6:547:2b7c:18ba,2a05:d018:12e3:f000:cbe5:cd29:1b3d:a00 exists in the SYSTEM.PEERS but missed in gossip.

2023-12-28 06:26:01.379: (ClusterHealthValidatorEvent Severity.ERROR) period_type=one-time event_id=68153b25-dda9-4bbb-ac7d-61740e0b7022: type=NodeSchemaVersion node=longevity-10gb-3h-2024-1-db-node-1de0fc08-2 error=Current node Node longevity-10gb-3h-2024-1-db-node-1de0fc08-2 [3.250.13.143 | 10.4.0.45 | 2a05:d018:12e3:f000:3eb0:1b2:d2e9:9d3d] (seed: True). Node Node longevity-10gb-3h-2024-1-db-node-1de0fc08-5 [54.247.62.163 | 10.4.2.136 | 2a05:d018:12e3:f000:cbe5:cd29:1b3d:a00] (seed: True) (ToggleAuditSyslog Node longevity-10gb-3h-2024-1-db-node-1de0fc08-1 [54.195.205.180 | 10.4.2.122 | 2a05:d018:12e3:f000:d86d:4b49:fff1:522e] (seed: True) nemesis target node) exists in the nodetool.status but missed in gossip.

[roydahan]

@juliayakovlev assigning to you after consulting @fruch who should prioritze.

[fruch]

fixed by #7047