Brainstorming TrRemoteConnection rearrangement

TrRemoteConnection

• This should contain everything required to connect to a remote node (right now it doesn't contain the public key, or whether the node will accept unilateral connections)

PROBLEM: If A connects to B unilaterally, then B doesn't have the ability to connect back to A because it doesn't have A's public key

So, we've been using TrRemoteConnection to identify nodes, even though we might not be able to connect to them.

So, we need to separate something that identifies a remote node, from something that allows us to connect to a remote node. eg. an IP address and port allow us to identify a remote node, but do not allow us to connect to it.

Also, a node's identity may be associated with multiple mechanisms to connect to it.

Worse, we could have several different identities for the same remote node.

Perhaps we need a notion of node identity that isn't tied to a specific transport, meaning that IP/port isn't a good identification mechanism.