dcsctp: Relax seq nbr handling for stream reset

The current implementation of the Stream Reset Handler strictly validates
incoming Re-configuration Request Sequence Numbers. If a request is a
retransmission (same sequence number), it immediately returns the cached
response, which was how RFC6525 was interpreted.

However, per recent discussions (and there will be an errata to clarify
this), if a request was previously responded to with "In Progress"
(because the Sender's Last Assigned TSN hadn't been reached), the
receiver must re-evaluate the condition upon receiving a retransmission.
The current implementation creates a deadlock with peers that does this:
The peer retransmits the same sequence number, and dcSCTP keeps replying
"In Progress" from its cache without checking if the TSN condition is
now met.

This CL relaxes the validation logic. If a request is a retransmission
and the last result was "In Progress", the handler will now re-evaluate
the state (check the cumulative ack against the sender's last assigned
TSN). If the condition is met, it proceeds to reset the streams;
otherwise, it returns "In Progress" again.

This change maintains backward compatibility with older peers (like
current dcSCTP senders) that increment the sequence number when retrying
after an "In Progress" response.

Following this CL, when it has reached a sufficiently large population,
the sender logic can be updated to send requests without incrementing
the sequence number when "In Progress" was the response.

Bug: webrtc:379844648
Change-Id: Icc3908a2e94e4a5bc0d350cae58bb8d844a27c1f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/427361
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#46261}