TLS session key re-negotiation

Session keys created by a TLS handshake are small and should be thrown out after a while (usually a certain number of payload bytes transferred within the session) to mitigate an attacker's ability to guess them.

The current handshake upcall does not support renegotiation. Instead, it treats a key reneg request as an error that is fatal to a session, then sets up a fresh session. This is typically not a significant problem because RPC connections/sessions are long-lived.

We would like the netlink upcall protocol and tlshd eventually to handle renegotiation. In this case, the upcall would pass a socket that already has a TLS session on it, and tlshd would redirect that to the library so that a reneg handshake can be done. The result should be that a fresh session key is plugged into the socket via setsockopt(3).

Start by reviewing the netlink upcall protocol and the tlshd handshake path described in the issue. Define how an upcall carrying an already-sessioned socket is redirected for renegotiation, and verify that a fresh session key is installed through setsockopt(3).