Noise handshake is inefficient

Currently, we use a XX handshake as part of the Noise spec.
X stands for: Static key for sender Xmitted ("transmitted") to recipient

So XX is used when we want A & B to chat with each other using an ephemeral key, while proving that they hold a static key.
This seem perfect in our scenario (the static key being our PeerId), except that this private key has to be Diffie–Hellman'ed, which is not possible with every form of PeerIds.

What we do instead is that we sign our ephemeral key using our PeerId key. But then, what's the point of the noise static key? Currently, we just generate a random one, and it serves a similar purpose to the ephemeral key.

Here is the current libp2p scheme, in noise terms:

-> e
<- e, ee, s, es, (PeerId public key, s signed by PeerId key)
-> s, se, (PeerId public key, s signed by PeerId key)

What we propose here is to lighten this scheme, by basing it on NN instead of XX:

-> e
<- e, ee, (PeerId public key, secret derived from ee signed by PeerId key)
-> (PeerId public key, secret derived from ee signed by PeerId key)

We should send only the signature of the secret derived from ee, not the secret itself!

This gets rid of s, es, and also fixes https://github.com/libp2p/specs/issues/355, since the signature now depends on data provided by both peers.

Unfortunately, this doesn't save much bandwidth, computation or RTTs, but still an improvement, and most importantly, fixes 355.

cc @s1fr0

Start by reading the Noise XX and NN handshake descriptions linked in the issue, then review the referenced issue 355 and the libp2p Noise specification. Compare the current message sequence with the proposed sequence, including what is signed and derived from the shared secret. Done means the protocol change is specified precisely and its compatibility and security implications are resolved.