Improve separation of transport and authentication layer

[ineiti]

@nikkolasg wrote on #333:
We've discussed that already with @jeffallen but I wanted to write it down for public scrutiny: I'm a little bit hesitant about "breaking" the interface in the router such as what's done here. The router should not care, should not know what precise implementation of the connection he is using. Of course the problem currently is that the router is doing the "authentication" (well, it's not even that but let's assume), by requiring an exchange of server identity on top of the connection. So there is a duplicate effort here with the TLS connection which already provides that, and has two consequences: (1) one more round trip for a ServerIdentity that we should not really need anymore (I guess it could be embedded in the certificate right ?) (2) it breaks the nice layer between a Router and its underlying transport. In order to solve that, that would maybe need some further restructuring like putting the authentication part one layer below: in the transport layer. The transport layer would then give a tuple (ServerIdentity, Conn) back to the router. For TLS connection, it seems possible to do that without too much hassle. For TCP connection, we can simply put the current authentication method down in the TCP stack, so when a new TCP connection is created, one expects a ServerIdentity exchange to happen, and then pass the tuple up to the router when ready. Same for Local connection.

Anyway, I'm not strongly suggesting that the current PR should not be merged, but merely proposing what I see as a smoother and nicer way to integrate real authentication in this stack.