This reverts commit 3180a5ad0663900a39adf4b9974052c356c835fe.
Reason for revert: Speculative revert due to failures in downstream tests.
Original change's description:
> dcsctp: Reset send queue when recreating TCB
>
> 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: I940e4690ac9237ac99dd69a9ffc060cdac61711d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261260
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Victor Boivie <boivie@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#36779}
Bug: webrtc:13994, chromium:1320194
Change-Id: I89bb9cae60adc53902c1304e79047d18e72594a5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261302
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Auto-Submit: Björn Terelius <terelius@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Victor Boivie <boivie@google.com>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36783}
7bd3bc105d