When uridecodebin exposes pads for its streams, we immediately ghost
the relevant (selected) one and let composition send a seek as soon as a
buffer is probed.
This means that sometimes uridecodebin is still linking elements
internally (for non-selected streams) and sees flush events travel down
the elements it is still busy trying to link / forward sticky events to.
This causes all sorts of nasty issues, which can be avoided by simply
blocking all data flow from the source until no-more-pads has been
emitted by uridecodebin (or whatever sub_element is wrapped).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3971>
This most likely never caused any issues as we don't connect to
no-more-pads in the first place, and the element isn't directly exposed
to the user, but emitting it makes no sense, and we are actually going
to connect to no-more-pads in a subsequent commit.
The call was added in 86b893e54c, a patch
by me in 2013, I have no idea why but I probably didn't have a firm
grasp on what I was doing then.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3971>
