CDRIVER-6045 Support TLS v1.3 in Secure Channel

[Julia-Garland]

Summary

Follow up to #2118. Handles the SEC_I_RENEGOTIATE status received when TLS 1.3 is enabled with Windows Secure Channel.

Background

Secure Channel with TLS 1.3 may use the renegotiate status for internal use; instructions on how to handle this are given in Windows documentation:

“The DecryptMessage (Schannel) function will return SEC_I_RENEGOTIATE when Schannel is ready for your application to proceed. When you receive the SEC_I_RENEGOTIATE return code, your application must call AcceptSecurityContext (Schannel) (servers) or InitializeSecurityContext (Schannel) (clients), and pass the contents of SECBUFFER_EXTRA returned from DecryptMessage in the SECBUFFER_TOKEN. After this call returns a value, proceed as though your application were creating a new connection.”

Note the C driver does not handle SEC_I_RENEGOTIATE for TLS 1.1 and 1.2.

Used libcurl as an implementation reference.

Changes

Upon receipt of SEC_I_RENEGOTIATE, the driver will pass the contents of SECBUFFER_EXTRA to InitializeSecurityContext by calling mongoc_secure_channel_handshake_step_2.

In some cases, the data processed by a read may be completely consumed by the renegotiate handling. If this occurs and the read is non-blocking, _mongoc_stream_tls_secure_channel_readv will call read again to receive and decrypt the next message.

Added some extra fields to mongoc_stream_tls_secure_channel to keep the necessary information in scope.

[kevinAlbs]

Well done. LGTM with a memory leak fix and possible comment tweak.

[kevinAlbs]

Suggest avoiding "to the server". I expect the call to InitializeSecurityContext processes the received SECBUFFER_EXTRA on the client.

Suggested change

	/* the tls handshake will pass the contents of SECBUFFER_EXTRA to the server */
	/* mongoc_secure_channel_handshake_step_2 passes the received SECBUFFER_EXTRA to InitializeSecurityContext */