Handle simulatenous auth for crypto handshake

[germsvel]

When performing the crypto handshake, we send an auth and expect to receive an ack. But it is possible that at the same time as we send an auth message to a peer, the peer is sending their auth message to us.

From "Creating authenticated connection" in the RLPx docs

1. initiator generates auth from ecdhe-random, static-shared-secret, and nonce (auth = authInitiator handshake)
2. initiator connects to remote and sends auth
3. optionally, remote decrypts and verifies auth (checks that recovery of signature == H(ephemeral-pubk))
4. remote generates authAck from remote-ephemeral-pubk and nonce (authAck = authRecipient handshake)

optional: remote derives secrets and preemptively sends protocol-handshake (steps 9,11,8,10)

... 5-7 omitted here

8. remote receives protocol-handshake
9. remote derives shared-secret, aes-secret, mac-secret, ingress-mac, egress-mac
10. remote authenticates protocol-handshake
11. remote sends protocol-handshake

Currently, we do not handle that optional scenario. If we send an auth message, we only expect to receive an ack message.

All of the logic for the crypto handshake currently resides in the ExWire.P2P module.

[hayesgm]

@germsvel Was this already addressed in #235 or #252?

[germsvel]

@hayesgm sorry for the late response. I don't know if this issue has been handled, but I also don't know if other clients actually do this. I think mana's flow assumes the peers will not preemptively send the protocol handshake. But I could be wrong.