quinnquic fails with large buffers in datagram mode

Describe your issue

In datagram mode, quinnquic sends a datagram with send_datagram without first calling max_datagram_size to check whether the current buffer to be sent fits into the currently available packet. If there is not enough space, gstreamer dies.

One way to circumvent this bug is to modify the upstream pipeline by, for example, setting rtph264pay's mtu to a relatively low value. This does work, but results in unnecessarily small packets most of the time.

Expected Behavior

quinnquic efficiently sends video in datagram mode (maybe by dynamically changing the upstream buffer size).

Observed Behavior

Gstreamer dies with:

ERROR: from element /GstPipeline:pipeline0/GstQuinnQuicSink:quinnquicsink0: GStreamer encountered a general resource error.
Additional debug info:
net/quinn/src/quinnquicsink/imp.rs(489): gstquinn::quinnquicsink::imp::QuinnQuicSink::send_buffer (): /GstPipeline:pipeline0/GstQuinnQuicSink:quinnquicsink0:
Sending data failed: datagram too large

Setup

• Operating System: debian
• Device: Computer/mininet
• gst-plugins-rs Version: commit ab2f5e3d
• GStreamer Version: GStreamer 1.22.0
• Command line: see below

Steps to reproduce the bug

We test involuntary migration when the QUIC client has two network interfaces to the QUIC server and the client's socket is bound to 0.0.0.0. In the middle of the transmission we switch the active network interface to "down". As a result, the transmission continues on the alternative path, but max_datagram_size() temporary returns lower values for a couple of packets, which the quinnquic element cannot handle. I understand this a rather complex setup, but the bug can be triggered with these simple, but unnatural commands:

gst-launch-1.0 -v \
   filesrc location=./cheetah.mp4 \
   ! decodebin ! x264enc ! rtph264pay mtu=5000 \
   ! quinnquicsink use-datagram=true secure-connection=false

gst-launch-1.0 -v \
   quinnquicsrc use-datagram=true secure-connection=false \
   ! application/x-rtp,media=video,clock-rate=90000,encoding-name=H264,payload=96 \
   ! rtpjitterbuffer ! rtph264depay ! decodebin ! autovideosink

Normally, one would not set the mtu to 5000, but this easily triggers the bug. (We plan to release our mininet environment later this year, in which the bug can be triggered by executing just one command.)

How reproducible is the bug?

The bug is always reproducible.

Screenshots if relevant

Solutions you have tried

We have implemented a segmentation algorithm relying on max_datagram_size(). This works but results in double segmentation as rtph264pay also segments frames into gstreamer buffers.

Related non-duplicate issues

Additional Information

Cc: @slomo @SanchayanMaity @levaitamas