Fix wrong SCTP stream parameters in SCTP DataConsumer that consumes from a direct DataProducer

[ibc]

Fixes #1515

Details

As exposed in the ticket #1515, let's assume this scenario:

• Alice and Bob create a WebRTC dataProducer with ordered: true (so a reliable DataChannel).
• In mediasoup side, there is a directTransport and a directDataConsumer which consumes those WebRTC dataProducer of Alice and Bob.
• The server runs some logic with messages received from Alice and Bob and then delivers those messages to Alice or Bob by using a directDataProducer created in that directTransport.
• For that to work, Alice and Bob create a WebRTC dataConsumer that consumes messages from that directDataProducer.

So what was the problem?

• dataProducers created on a directTransport are always reliable. Why? Because they send messages through the mediasoup UnixSocket which is a reliable transport.
• So it makes sense that when we create a WebRTC dataConsumer in a webRtcTransport that consumes that directDataProducer, such a dataConsumer should be reliable (it should have directDataConsumer.sctpParameters.ordered === true.
• However this was not true! Or in other words, this was only true if webRtcTransport.consumeData() was called with ordered: true explicitly. But the point is that by default it should be reliable (so ordered: true) because we are consuming from a directDataProducer that is reliable/ordered by design.
• So at the end, assuming we don't include ordered: true in webRtcTransport.consumeData(), the resulting dataConsumer (which is the one that will deliver messages to the browser) is unreliable (it has dataConsumer.sctpParameters.ordered === false) so messages sent to the browser could reach the browser out or order and be dispatched by the browser WebRTC PeerConnection out of order, and some messages could be lost!
• So imagine that Alice sends messages "A", "B" and "C" to mediasoup, those messages travel through the directTransport blablabla and finally they are sent to Bob via WebRTC dataConsumer. It could happen that Bob receives "C" and "B" (in that order). Ok, that can always happen due to network conditions, but the problem is that, since the dataConsumer is configured as unreliable (it has ordered: false) the dataConsumer in Bob's browser will dispatch "message" events in that wrong order, this is: "C" and "B".
• Note that if the dataConsumer was reliable, then the WebRTC engine of the browser would buffer "C" and "B" and wouldn't dispatch them to the app until "A" is received, and it would dispatch them in order: "A", "B", "C".
• And even worse: mediasoup would try to retransmit "A" N times (depending on sctpParameters.maxRetransmits) and if none of the retransmissions of "A" reaches Bob's browser, the webRtcTransport of Bob in mediasoup side won't emit "sctpstatechange" with state: 'closed'!

Good news

This is fixed in this PR.

[ibc]

@jmillan please don't approve this yet, I'm still working on the Rust changes.

[jmillan]

@jmillan please don't approve this yet, I'm still working on the Rust changes.

I wonder why GH allows approving a draft PR. Please, reassign it to me when done.

Optimistic PR review.

[ibc]

@jmillan please don't approve this yet, I'm still working on the Rust changes.

I wonder why GH allows approving a draft PR. Please, reassign it to me when done.

PR ready.

[ibc]

Released in mediasoup 3.15.7.