feat: storing multiple ip, host and port entries per NodeId

[tegefaulkes]

Specification

With the realisation that a NodeId -> address is a many to many relationship. We need to expand the NodeGraph functionality to enable the ability to track multiple addresses per node. This can be acheved by expanding the level structure from bucket/NodeId -> nodeAddress to bucket/nodeId/[ip4|ip6|host]/port -> null. This should allow us to track multiple nodeId -> Ip4|ip6|host:port mappings in a set like fashion.

The utility of this needs to be reviewed. A nodeId refers to a single running node. There should only be one valid IP:PORT address for that node at any given time. So we only really need to track the latest address information for any node. A host could resolve to multip;e 'A' or 'AAAA' records and we'd have to check each one but we'd only store the hostname for that.

Additional context

• Local Network Traversal - Multicast Discovery js-mdns#1 - local discovery can introduce ambiguities, and this can be recorded by the node graph
• Integration Tests for testnet.polykey.com Polykey-CLI#71

Tasks

1. Refactor NodeGraph level structure to be bucket/nodeId/host|ip/port -> null to enable tracking of multiple addresses.

[CMCDragonkai]

This will be needed for MatrixAI/js-mdns#1.

[CMCDragonkai]

From #485:

I suppose #482 still needs to be addressed but I don't think it's high priority or even needed right now. We may need to track the last known hostname, public IP and private IP of a node. The private IP would be needed to coordinate connecting to nodes on the same network but that's a feature for later.

If we allow for multiple address records per nodeId then instead of overwriting the same record we end up adding new records. This could lead to this data bloating over time if we don't have a clean up policy.

But like I said, I don't think #482 is needed right now so it can be addressed when we need that functionality.

[CMCDragonkai]

This is related to #537.

[tegefaulkes]

This should be fixed by the #537

Or maybe it's made obsolete by #537?

[CMCDragonkai]

This is done. It's already available in the NodeGraph.