Fix TLS endpoint port propagation in gossip

[Mallets]

Properly store the TLS listener locator and endpoint as returned by the OS upon socket opening.

[oteffahi]

In QUIC link this is local_addr.to_string(). Not sure if it can be different from locator.address() in this case.

[Mallets]

local_addr.to_string() allocates and then the creation of the EndPoint creation allocates a second time. locator.address() returns &str so it allocates one time less.

[oteffahi]

I was more concerned about if the contents of the two variables diverge. Indeed there is a case where they diverge, it seems that locator.address() contains the unresolved hostname, while local_addr contains the resolved one.

For example (on MacOS) when listening on localhost:0:

• locator.address(): "localhost:49999"
• local_addr.to_string(): "[::1]:49999"

[oteffahi]

Looks like multicast scouting fails to connect when the propagated locator is tls/[::1]:49999, so it's correct to use locator.address(). Will check if QUIC link also has this issue

[Mallets]

The unresolved address, i.e. locator.address(), should be used in my opinion since the listener has been created on a DNS name. Propagating the already resolved address could lead to some hidden problem about DNS caches in zenoh. Let's every host resolve the IP address from the DNS name based on its own DNS configuration.

[oteffahi]

After some testing, I can confirm there is a similar issue on QUIC.

[oteffahi]

local_addr.to_string() should be replaced by format!("{host}:{}", local_addr.port()) (after computing host variable like so).

zenoh/io/zenoh-links/zenoh-link-quic/src/unicast.rs

Lines 423 to 428 in 911382d

	let endpoint = EndPoint::new(
	endpoint.protocol(),
	local_addr.to_string(),
	endpoint.metadata(),
	endpoint.config(),
	)?;

[Mallets]

Just added

[oteffahi]

LGTM.