threadshare: Operating on a Context without a valid PadContext

This one requires a sender and a receiver pipeline, and exhibits both the error in the title, and while tearing down the issue reported in #93 (closed) .

Sender:

gst-launch-1.0 audiotestsrc do-timestamp=true samplesperbuffer=400 ! alawenc ! rtppcmapay max-ptime=50000000 min-ptime=50000000 ! udpsink host=127.0.0.1 port=50000

Receiver:

gst-launch-1.0 ts-udpsrc port=50000 address=127.0.0.1 context="1" caps="application/x-rtp, media=(string)audio, clock-rate=(int)8000, encoding-name=(string)PCMA, payload=(int)8" ! rtppcmadepay ! alawdec ! ts-proxysink proxy-context="11" ts-proxysrc proxy-context="11" ! fakesink

stack.txt

Let's keep the discussion about block_on in #93 (closed) , regarding this new panic what I've observed is that it occurs because audiodecoder forwards its stream start immediately, keeping the custom downstream pad context event in a list of pending events (audioencoder also does that btw).

If I patch audiodecoder to forward all pending sticky events prior to forwarding stream_start, the issue disappears, I don't think we want to require this behaviour however? The issue also disappears if I replace ts-udpsrc with a regular udpsrc, it's not entirely clear to me why but worth reporting :)