protocol: resolve TLS transport from the bound session, not thread-local io_ssl

file_send.c chose between sendfile() and the TLS-aware buffered path by
calling io_get_ssl(), which reads the thread-local io_ssl. A worker thread
that bound a TLS ProtocolSession via protocol_session_bind() never ran the
handshake in that thread, so io_ssl is NULL there and a TLS + --threads
transfer took the raw sendfile() path on an encrypted socket.

Add protocol_current_ssl(), which prefers the bound session's SSL and falls
back to io_ssl on the fd-shim path, and use it in file_send.c. Un-xfail
test_tls_with_multithreading.

src/shared/protocol.h

@@ -216,6 +216,15 @@ void io_set_bwlimit(unsigned long long bytes_per_sec);
 unsigned long long io_get_bwlimit(void);
 void io_set_ssl(SSL* ssl);
 SSL* io_get_ssl(void);
+/* SSL object of the transport in effect on this thread: the currently bound
+ * session's SSL when a session is bound, otherwise the legacy thread-local
+ * io_ssl.  NULL for a plaintext transport.  Unlike io_get_ssl(), this resolves
+ * worker threads that bound a TLS session via protocol_session_set_ssl()/
+ * protocol_session_bind() but never called io_set_ssl() themselves (C11
+ * _Thread_local state is not inherited by a new thread).  Callers that must
+ * choose a TLS-only code path (e.g. file_send.c's sendfile fallback) must use
+ * this instead of io_get_ssl(). */
+SSL* protocol_current_ssl(void);
 
 /* Process-wide wire byte counters.  protocol_send_n_data/protocol_receive_n_data
  * update them; the zero-copy sendfile path reports through