WIP: rtpjitterbuffer: add failing test that reproduces a stall

So what happens here is that at some point we receive packet #10508, which triggers the big gap logic, placing that buffer inside the gap_packets GList:

gst_rtp_jitter_buffer_chain: expected #10529, got #10508, gap of -21
handle_big_gap_buffer: buffer too old -21 < -20, first one - waiting

Then packet #10550 arrives:

gst_rtp_jitter_buffer_chain: expected #10530, got #10550, gap of 20

This causes too many timers to be pending, causing a reset:

gst_rtp_jitter_buffer_chain: 182 pending timers > 180 - resetting
gst_rtp_jitter_buffer_reset:< flush and reset jitterbuffer

Inside the reset() code, the next_seqnum is set to the first buffer in gap_packets, #10508:

gst_rtp_jitter_buffer_reset: setting next_seqnum to #10508

And reset() calls chain() with all its gap_packets, pushing it out:

gst_rtp_jitter_buffer_chain: Received packet #10508 at time 123:45:05.364650711, discont 0, rtx 1

However, #10508 is actually an RTX packet, so it gets dropped:

gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> Unsolicited RTX packet #10508 detected, dropping

Next #10550 is pushed from reset():

gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> Received packet #10550 at time 123:45:05.516136868, discont 0, rtx 0

But because next_seqnum is set to #10508, we get this:

handle_next_buffer: Sequence number GAP detected: expected 10508 instead of 10550 (42 missing)

So now the jitterbuffer is completely stalled, all buffer arriving now will just queue up until it sees the promised #10508, which will be ~65000 packets from now, and we will trigger the "full" logic before then, causing a deadlock.