[MSE][GStreamer] block data flow until source pad is exposed

[emutavchi]

There could be a race between main thread (linking typefind element, see gsturisourcebin.c:setup_typefind) and streaming thread (pushing data). webKitMediaSrcLoop does wait for source pad to linked. However, there is no guaranty that peer pad is already active at that point. Which may lead to data loss while peer pad is being activated.

The issue can be reproduced with https://emutavchi.github.io/tests/mse/mse_data_loss_test.html. Run browser with extra logging: 'GST_DEBUG=webkitmediaplayer:6,webkitmediasrc:7,GST_SCHEDULING:6,typefind:5,2', and watch the logs. After several runs you should see instances of webkitmediasrc silently dropping buffers:

0:00:07.087186057    38  0x2a8cce8 TRACE         webkitmediasrc WebKitMediaSourceGStreamer.cpp:815:webKitMediaSrcLoop:<source:src_A0> Pushing buffer downstream: buffer: 0x2a7c4c8, pts 0:00:00.000000000, dts 0:00:00.000000000, dur 0:00:00.042666666, size 341, offset none, offset_end none, flags 0x4040
...
0:00:07.087275204    38  0x2a8cce8 LOG           GST_SCHEDULING gstpad.c:4715:gst_pad_push_data:<source:src_A0> error pushing events, return flushing

This change adds a data prob that blocks downstream flow during pad exposure, allowing urisourcebin to link/activate typefind sink pad.

[emutavchi]

Attached logs with reproduction console.log.gz