dcsctp: Reset send queue when recreating TCB

This is a re-land of commit 3180a5ad0663900a39adf4b9974052c356c835fe.

This is an issue found in fuzzer, and doesn't really happen in WebRTC
as it never closes the connection and reconnects.

The issue is that the send queue outlives any connection since you're
allowed to send messages (well, enqueue them) before the association is
fully connected. So the send queue is always present but the TCB
(information about the connection) is torn down when the connection is
closed for example. And the TCB holds the Stream Reset handler, which is
responsible for e.g. keeping track of stream reset sequence numbers and
such - which is tied to the connection.

So to ensure that the Stream Reset Handler is in charge of deciding
if a stream reset is taking place, make sure that the send queue is in
a known good state when the Stream Reset handler is created.

Bug: webrtc:13994, chromium:1320194
Change-Id: Ib8254488523c7abb58057c602f76f411fce896fa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265000
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37115}

net/dcsctp/socket/dcsctp_socket.cc

@@ -1316,9 +1316,6 @@ bool DcSctpSocket::HandleCookieEchoWithTCB(const CommonHeader& header,
     RTC_DLOG(LS_VERBOSE) << log_prefix()
                          << "Received COOKIE-ECHO indicating a restarted peer";
 
-    // If a message was partly sent, and the peer restarted, resend it in
-    // full by resetting the send queue.
-    send_queue_.Reset();
     tcb_ = nullptr;
     callbacks_.OnConnectionRestarted();
   } else if (header.verification_tag == tcb_->my_verification_tag() &&