Need to know the expected PublicKey in upgrades

[tomaka]

When negotiating the encryption protocol, we can remove one roundtrip by knowing the public key of the remote in advance. This requires some changes in the APIs.

cc #881

[tomaka]

One idea would be to pass the expected public key to Transport::dial, then to the closure of Transport::and_then, and build the connection upgrade on-the-fly.

However this raises questions:

• Is it valid for a transport to return a peer identity that is different from the expected one?
• Should the peer identity be a generic, or hard-coded to a specific type?

[burdges]

I'd expect you know this, but.. We only need one party A to know the public key of the other party B, because the handshake can send A's public key to B encrypted behind ee and es key exchanges. We've slightly different handshakes that determine if A or B initiates the connection.

[tomaka]

#888 has been merged but is not usable in practice because of this issue.

[twittner]

@tomaka, It depends on the handshake pattern. One could use XX for instance which works without pre-shared static keys. The IK pattern of course requires this issue to be resolved first.

[thomaseizinger]

Closing in favor of #2946.