This allows disabling these track types when stream info has been not
loaded while the ExoPlayer instance is.
It is now possible to do so with the background player, in order to
disable fetching video and text tracks for manifest sources,
especially used for livestreams.
Also set the recovery first before reloading play queue manager in the
useVideoAndSubtitles method of the Player class.
This partially reverts commit 92a07a34456c5df560454a335f89ba677719c313, which was needed to fix ghost notifications. There I broke the "cycle" causing the useless notifications to popup in 2 different places (see points 3 and 4 of the commit description).
However, breaking the cycle in point 4 ("`PlayerHolder::tryBindIfNeeded()` is now used to passively try to bind, instead of `PlayerHolder::startService()`" was not correct, for the following reason.
I assumed that `ACTION_PLAYER_STARTED` was used for notifying that the player was instantiated anew, while it actually is used to notify that something is now ready for use: it could be the player, but it could also just be that the bottom sheet view was just added and thus the VideoDetailFragment needs to start the player.
Therefore, when handling `ACTION_PLAYER_STARTED` it is correct to start the player service and not just try to bind to it.
The other point in which I broke the cycle (point 3) should still prevent ghost notifications, although I could not test.
The bug is caused by a wanted but forgotten inconsistency in the database.
A stream can be listed in the watch history (StreamHistoryEntity) while having no corresponding playback state (StreamStateEntity) containing the matching playback position. This is caused by the fact that NewPipe does not consider a watch time of less than five seconds to be worthy to be put into the StreamStateEntity because the video was most likely played by error. Those videos are, however, counted and stored in the watch history.
Turned out this bug was already fixed two years ago but unfortunately
it made its way back again. It was solved in #9642 but back then another
method was used for querying playlists from db (for add playlist dialog) then in
ef4a6238c88f26e50ba794caa071432a08da66e7 was introduced another method
which had the same problem as fixed in #9642 and which eventually replaced
original method in code for querying playlists from db (for add playlist dialog)
Call `saveImmediate` only after used actually dropped item instead
of every time View is updated which happens several times to show
user a feedback where item would be moved
