adaptivedemux: do not retry downloads during shutdown.

This is RFC, the other adaptivedemuxer's probably have similar behavior to HLS that would need patching, although I don't have test scenarios for those ones.

The high-level issue here is that I get deadlocks during state changes inside the HLS demuxer. In WebKit, we use a custom websrc (not souphttp). This web src requires rendezvous on the main thread for network updates (e.g., buffer received from the network). What happens in the HLS demuxer is that when it sees an EOS on the manifest file on its src_pad, it starts to download the HLS fragments.

During this download window, the MANIFEST_LOCK is taken, and it waits for the fragment to be downloaded. If, during this window, our media player destructs, it calls change_state on the HLS demuxer. This deadlocks because the MANIFEST_LOCK is held by the fragment downloader, which will never update because now the main thread is deadlocked in a change_state, which is where rendezvous happens for network ops in WebKit.

The solution for me is to cancel all pending downloads in the demux and ensure its retry logic doesn't scupper me in the process of PAUSED->READY, before we try and take the MANIFEST_LOCK in adaptivedemux's change_state vfunc.

Any comments on the approach appreciated. The cancelled_downloads field is unprotected, because in general the locking story inside HLS demux is a bit confusing, for example the manifest field is sometimes locked, and sometimes not.