Migrate from callbacks to sockopts

[npmccallum]

Currently, the HANDSHAKE sockopt calls callbacks. Let's move to socket options instead of callbacks.

[npmccallum]

The new code should define two new socket options: TLS_PSK_USER and TLS_PSK_KEY. These can be used with either getsockopt() or setsockopt().

Inside the handshake function, we need to determine if the peer wants to use authentication (PSK or otherwise). If so, we need to return ENOKEY. This tells the caller that authentication credentials need to be supplied and then handshake needs to be called again. We use ENOKEY rather than EAGAIN because the former indicates to call handshake without polling for data and EAGAIN indicates to poll for data.

After the caller receives ENOKEY, they must call setsockopt() to provide the authentication credentials. Clients must provide both TLS_PSK_USER and TLS_PSK_KEY. Servers should call getsockopt(TLS_PSK_USER) and then call setsockopt(TLS_PSK_KEY) to set the proper key for the user.

@frozencemetery @puiterwijk Thoughts?

[frozencemetery]

I agree with the idea of moving away from callbacks - that's closer to the design I went with in GSSAPI as well.

My one concern would be making sure that the same interface works with the different TLS backends we have, but barring that, it sounds good to me.

[puiterwijk]

So, I think that this might work reasonably, but we should make sure there's a way for the application to figure out what kind of keys they are requested to set (PSK user/pass, cert/key, ...).
I'm wondering whether we might offer the possibility to set the socket options with PSK user/pass or cert/key ahead of calling the handshake (if you are entirely sure what credentials you're going to be using, and there's no distinction for which ones (e.g. SNI and different certificates)).

I do think this makes it less clear that all of these options can be clearer again after handshake: the memory management could become somewhat more complicated: Does tlssock copy option values or do we expect pointers to options to remain valid for the duration of the handshake? How about post-handshake for a renegotiation or re-authentication?