Investigate external/internal ip for network discovery.

[dj8yfo]

The fact, that node is sending initially statically defined addr of itself in Connect message may be problematic for deployment of nodes across different networks/organisations.
In general case, a node cannot know its own ip, as seen by another peer, without using external services.
Moreover, a node's ip may vary from different peers' perspective.
#16
https://*********/projects/22/tasks/1307

[vldm]

For now #214, we have different external and listener ip in config, this should partially helps to deploy node in WAN.

For now, we should split this task into two sub cases:

• Node can work with more than one interface and ip respectively.
• There should be some mechanism to resolve external ip

Additionally there some problems revealed during discussion:

1. Sometimes auditor node could be outside internal subnet, this allows validator's peer-exchange to reveal auditor ip to other validators. May be auditors should be outside peer-exchange mechanism.
2. With more than one external ip, there should be feedback from outgoing connections, to check if we connect to valid validator.

[alekseysidorov]

As workaround we can define external addresses transformation table with the such format:

[peer_external_adresses]
"peer_pubkey" = "ip_addr_in_our_subnet"

[stanislav-tkach]

Closed by #406.