Make SCTP stream reset and reuse generation-safe

[idy]

What changed

• expose reset-completion notifications and negotiated inbound/outbound stream limits
• retain stream ownership until both reset directions have completed
• keep delayed acknowledgements and retransmitted or stale reset requests from affecting a reused stream ID
• keep a single outgoing reset request in flight and bound the number of stream IDs per request
• complete pending incoming reset requests when the cumulative TSN advances through FORWARD-TSN or I-FORWARD-TSN, and re-evaluate a retransmitted request that is still in progress instead of replaying the cached "In progress" response
• ignore a late response to an outgoing reset for a stream the peer has already reused, instead of resetting the new generation's outgoing sequence numbers
• copy configured inbound and outbound stream limits into client and server association options

Why

WebRTC needs to reuse SCTP stream IDs after a DataChannel closes, but an ID is not safe to reuse until the reset procedure has completed in both directions. Delayed acknowledgements or a retransmitted reset request from the previous stream generation must also not close or mutate the new generation.

An incoming reset request whose Sender's Last Assigned TSN is ahead of the cumulative TSN is answered "In progress". When the peer closes a partially reliable stream whose last message was abandoned, that gap is closed by (I-)FORWARD-TSN rather than DATA, and the reset previously never completed unless more DATA arrived later.

When a stream ID is reused immediately after its reset completes, the response to our own outgoing reset for the previous generation can arrive after the new generation has already sent data. Applying it then reset the new generation's outgoing MID/SSN, so the next message repeated sequence number 0 and was never delivered by the peer.

Scope

This supersedes #485, which was opened from a branch that also carried unrelated fixes. Those are now separate PRs:

• Ignore duplicate INIT on established association #495 ignore duplicate INIT on an established association
• Allow a separate handshake retransmission timeout #496 separate handshake RTO max
• Release WFQ stream finish state when idle #497 release WFQ stream finish state when idle
• Rearm T3 after RACK tail loss probe #498 rearm T3 after RACK tail loss probe

Relationship to #463

This is an alternative implementation that covers the stream-limit and reset-completion goals of #463 and adds the lifecycle and retransmission handling needed by the corresponding WebRTC integration. As discussed in #485, we are happy to combine this with #463 or rebase on top of it once it lands, whichever maintainers prefer.

Validation

• go vet ./...
• go test -race ./...

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.61%. Comparing base (597b321) to head (e815877).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #494      +/-   ##
==========================================
+ Coverage   85.50%   85.61%   +0.11%     
==========================================
  Files          56       56              
  Lines        5465     5535      +70     
==========================================
+ Hits         4673     4739      +66     
- Misses        556      558       +2     
- Partials      236      238       +2     

Flag	Coverage Δ
go	85.61% <100.00%> (+0.11%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[JoTurk]

Can you please break or simplify this?
can you also check https://github.com/pion/webrtc/wiki/Contributing#ai-assisted-pull-requests