API to directly open TLS connections, instead of upgrading an existing socket

Background: currently to get a TLSSocket, you first create a non-encrypted Socket, then upgrade it via TLSContext to get a TLSSocket. This proposal is for new TLSContext APIs to directly create client/server TLSSockets.

Motivation:

• On Native, s2n-tls is capable of interfacing directly with the underlying socket's file descriptor. This should have higher performance and is probably easier to implement than redirecting it through an FS2 Socket.

  Even more compelling, s2n-tls also supports using Kernel TLS, where all the encryption/decryption happens in kernel-space. This minimizes data copies.

• On JS, the upgrade is implemented by a costly Node.js Socket <-> FS2 Socket <-> Node.js Socket <-> Node.js TLS Socket <-> FS2 TLS Socket conversion. In Node.js it is possible to directly open TLS connections/servers directly, and thus skip a few layers of conversion.

I'm not aware of any motivation to do this on the JVM, at least with the JDK. Probably a hypothetical Netty-based TLSContext could take advantage of this.

Questions:

1. Could e.g. Ember and Skunk take advantage of such an API, instead of manually upgrading?
2. Alternatively, could we make these optimizations within the upgrade mechanism, without exposing a new API? Seems hard, since in theory the user could continue doing things with the raw Socket even after upgrading it. If we assume that won't happen, then maybe it can work.

Start by reviewing the existing TLSContext APIs and the socket-upgrade mechanism described in the issue, then investigate whether Ember and Skunk could use direct client/server TLSSocket creation. The issue needs a decided API or optimization scope before implementation can be considered done.