feat(webrtc): implement fin ack

[tesol2y090]

Description

Implements FIN_ACK support for WebRTC streams to ensure reliable closure handshaking as specified in the WebRTC spec. This adds:

• FIN_ACK flag handling in state machine
• Timeout mechanism for FIN_ACK wait
• Proper state transitions for graceful closure
• webrtc: support FIN_ACK #4600

Notes & open questions

• Using Instant for deadline tracking instead of tokio timer to avoid extra dependencies
• Timeout is set to 10 seconds - should this be configurable?
• State machine ensures FIN_ACK is only sent/processed in appropriate states

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
  • Added documentation for FIN_ACK related functions
  • Updated state machine documentation
• I have added tests that prove my fix is effective or that my feature works
  • Added tests for FIN_ACK state transitions
  • Added tests for timeout behavior
  • Added tests for edge cases

[elenaf9]

Thank you for your contribution @tesol2y090 and sorry for the delay here! Will try to give this a review in the next days.

[elenaf9]

Sorry for the delay here @tesol2y090.

Some first comments.

[elenaf9]

Not sure about this, but don't we need to somehow continue reading here to be able to receive the FIN_ACK?

With AsyncWriteExt for instance a future will be created that only returns after poll_close succeeded i.e. no concurrent call to poll_read happens. With the current impl, I don't think a FIN_ACK will ever be read in that case?

On the other hand, we'd then have to discard the read messages or buffer them. Not sure how this is handled e.g. in QUIC, or in the go implementation.

[elenaf9]

So I looked into the QUIC and TCP transports to check how they handle this in their poll_close function.
However, as far as I can tell neither of them wait in poll_close for the sent FIN to be acknowledged in the first place.

Unfortunately I couldn't find any prior discussion about this.

[mergify]

This pull request has merge conflicts. Could you please resolve them @tesol2y090? 🙏

[elenaf9]

Regarding whether poll_close should wait for the FIN_ACK or not (see #5687 (comment)).
As already mentioned, the current implementation won't work when there are blocking calls to close().await, because without a concurrent call to poll_read the corresponding FIN_ACK will never be read and we'll always timeout.

If the read side is closed anyway, we can just read from within poll_close, parse the flags, and discard any other messages analogous to how poll_write is doing it.

If the read side isn't closed yet we have two options:

1. Don't wait for the FIN_ACK. But that would mean that we wouldn't have the guarantee that all data has been received.
2. Read from the stream and buffer the incoming messages up to a BUFFER_MAX (I think we can use the existing read_buffer for that?). If the max has been reached before the FIN_ACK we just return same like in case of a timeout.

I think we should go with nr. 2, but I wonder if there are any better options that I didn't think of (cc @dariusc93 @jxs).
What do you think @tesol2y090?