Provide hostname for SNI

[mmastrac]

The hostname negotiation for SNI may be different from the connection address. For example, a client may connect by IP to a service and provide an unresolved hostname on connection. As in #14, this SNI negotation result may need to provided as part of the handshake promise.

[jasnell]

Absolutely agree. I'd like to see hostname and ALPN accepted as arguments.

For background, we very intentionally limited the options that can be specified on connect() initially because we didn't want to go the Node.js route and offer every option anyone might ever want without clearly understanding what would actually be the most useful. We want to be far more selective about how these are added.

I think it is safe to say, however, that SNI and ALPN are definitely Must Haves.

[mmastrac]

Definitely -- both of those may be required for a successful HTTP/2 or gRPC connection, for example. In terms of TLS options, I'd suggest these are probably the two most important and most common.

[jasnell]

Would you be interested in opening a PR adding these? I think we ought to be able to keep it pretty simple, e.g.,

const socket = connect('...', { secureTransport: 'on', sni: 'example.org', alpn: ['h1', 'h2'] });
await socket.opened; // see https://github.com/wintercg/proposal-sockets-api/pull/12
console.log(socket.info.sni);  // the negotiated sni. undefined before handshake is complete
console.log(socket.info.alpn); // the negotiated alpn. undefined before handshake is complete

[mmastrac]

@jasnell Opened a PR for it. Some further comments in #18

[jasnell]

This has been added.