feat: get NodeInfos from the MagicEndpoint

[ramfox]

Description

Call MagicEndpoint::node_infos() to get a Vec<NodeInfo>, or list connection information on all nodes we know about.

NodeInfo is aliased from super::magicsock::EndpointInfo.

/// The type of connection we have to the node.
#[derive(Debug, Clone, Eq, PartialEq)]
pub enum ConnectionType {
    /// Direct UDP connection
    Direct(SocketAddr),
    /// Relay connection over DERP
    Relay(u16),
    /// We have no verified connection to this peer
    None,
}

/// Details about an Endpoint
#[derive(Debug, Clone, Eq, PartialEq)]
pub struct EndpointInfo {
    /// The id in the peer_map
    pub id: usize,
    /// The public key of the endpoint.
    pub public_key: PublicKey,
    /// Derp region, if available.
    pub derp_region: Option<u16>,
    /// List of addresses at which this node might be reachable, plus any latency information we
    /// have about that address.
    pub addrs: Vec<(SocketAddr, Option<Duration>)>,
    /// The type of connection we have to the peer, either direct or over relay.
    ///
    /// Depending on the expiry time, we may still have a direct connection to the peer
    /// but our best address for the peer may have timed out.
    /// Until we verify that connection, we assume that we may only have a relay
    /// connection to that peer.
    pub conn_type: ConnectionType,
    /// The latency of the `conn_type`.
    pub latency: Option<Duration>,
}

Notes & open questions

Please let me know if the above EndpointInfo + ConnectionType is enough for our UI and sync purposes!

Change checklist

• Self-review.
• Documentation updates if relevant.
• Tests if relevant.

[b5]

We've been shifting away from Peer as a term since #137 , what do you think about NodeInfo?

[Frando]

nit: maybe active_connections or so? node_infos to me sounds a bit more static than what this method does. but also not sure myself, it's fine to leave it as is.
edit: I'm just now realizing that I don't actually know - Entries are added whenever you connect to a new node. But when are entries dropped from the magicsocket's state? Never? After a timeout? Let's maybe mention this in the docs if you know the answer.

[ramfox]

I did some reading. We do delete endpoints, but it is currently only triggered by user action. Any time we set_network_map, we remove any connections that were made to us "in the wild".

But the only method that calls set_network_map is add_known_addrs. Which... is an interesting side effect that we haven't really surfaced. I'm not sure that we intended to have every time we add a new address to the netmap, that it should clear all connections made by other nodes to us.

However, since this happens only on user action, we are likely carrying around a bunch of "inactive" connections, so until / unless we change this, I don't think active_connections is the best name.

@b5 I think ConnectionInfo might be the right name for the EndpointInfo outside of the MagicSock.

which would make this connection_infos & I will add the above context into the function docs for both connection_infos and add_known_addrs.

[dignifiedquire]

NodeInfo is very confusing to me, I think it should be at least sth like RemoteNodeInfo, otherwise I would assume it is the local node

[b5]

NodeInfo is very confusing to me, I think it should be at least sth like RemoteNodeInfo, otherwise I would assume it is the local node

Fully support this change. RemoteNodeInfo is a longer, but much clearer name

[ramfox]

Out of band discussion, we settled on ConnectionInfo

[ramfox]

closing this PR in favor of #1435