smbXsrv_client: move the connection passing to smb2srv_client_mc_negprot_send/recv

smbXsrv_client: move the connection passing to smb2srv_client_mc_negprot_send/recv

We need a full request/response pair in order to avoid races in
the multichannel connection passing.

smb2srv_client_mc_negprot_send/recv locks the
db record for the given client_guid.

If there's no entry found, we add ourself and
return NT_STATUS_OK.

If there's an existing process for that client guid
we start messaging_filtered_read_send()
dbwrap_watched_watch_send() before calling
smb2srv_client_connection_pass().

Then we release the lock and wait for either
MSG_SMBXSRV_CONNECTION_PASSED to arrive or
retry if dbwrap_watched_watch_recv signaled
a change in the database.

If we got MSG_SMBXSRV_CONNECTION_PASSED we'll
return NT_STATUS_MESSAGE_RETRIEVED in order to
signal that the other process will take care of
the connection and we terminate the current process.

All that is done completely async, which means that
the IDLE_CLOSED_TIMEOUT (60 seconds) may trigger
deadtime_fn(), which will send itself a MSG_SHUTDOWN.
So the process that accepted the tcp connection
exists if there was no MSG_SMBXSRV_CONNECTION_PASSED
within 60 seconds.

However the fd may still exists in the kernel (and
the new connection may still be handed to the other
process. If that process somehow exists before
there's no way to prevent a connection termination
for the client.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=14433

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Sat Mar  6 03:30:06 UTC 2021 on sn-devel-184