webrtc: update str0m, fix multistream message decoding and encoding

[timwu20]

Changes

• updates the str0m dependency to the commit which contains fixes I co-authored (PR #1, #2)
  • fixes str0m integration based on breaking public API changes
  • currently the references the latest commit hash, will update again when a release is cut by @algesten
• fixes the decoding of multistream messages to support messages without trailing linebreak
• removes trailing linebreak when encoding multistream message used for WebRTC
• sets the channel low buffer amount threshold to 1024 bytes, and listens on Event::ChannelBufferedAmountLow to close a substream/rtc channel.
• contributes to webrtc: Test the connection stability of the webrtc substreams #420

[lexnv]

Was this observed with smoldot integration?

[timwu20]

This was observed when testing against the libp2p native WebRTC transport. During negotiation, the libp2p native WebRTC transport doesn't append an extra newline.

[lexnv]

We could reach out to https://github.com/smol-dot/smoldot to align on the spec, then we could remove/simplify these functions.

We have diverged a bit from the spec, I wonder if this may break things down the line. Would the next message be interpreted correctly?

[timwu20]

We have @freddyli7 working on utilizing smoldot as a client to test against the libp2p server, as well as the litep2p server. We plan on getting it into litep2p-perf to run the performance behaviour. If things are incorrect in smoldot, we will create PRs upstream to fix them.

[algesten]

@timwu20 I released 0.11.1

[timwu20]

Added 8cf27e9 which calls Channel.set_buffered_amount_low_threshold to set the threshold to 1024 bytes, and listen on this event to close the channel if the protocol behaviour intends to close the substream.

With this change I'm able to get litep2p-perf to run the performance behaviour using a litep2p server utilizing WebRTC transport to upload 16MB of data to a libp2p WebRTC client. Any byte counts higher than that cause the connection to get dropped because of the lack of ICE keep-alive requests. I believe this has to do with the lack of proper back pressure when writing on the server side. I think we can address this further in issue #45.