Fix to allow Audio timestampMaster causes stream startup delay

The patch, allow audio master, commit [6f8a8f](https://github.com/google/ExoPlayer/commit/6f8a8fbc1cf974617056edac6ee0068b175a6454), fixes stall issues with ordering of updates of the DSN in segments across demuxed renditions however the cost is the seconds of delay on channel change or stream startup, a bad user experience.

To reproduce this bug start playback of any HLS live stream where audio timestamps precede video in the sequence of segments.

* Expected:
1. Initial load of video sets start time reference
2. Audio render is not started (samples are discarded, until they match video time)
3. Playback starts immediately after first frame shows (early audio samples are discarded)

* Actual:
1. Audio playback starts immediately
2. First frame shows immediately (as this is a forced render, `MediaCodecVideoRenderer` forces first frame in `processOutputBuffer()`
3. First frame is frozen until all audio preceding it plays out

This change to allow audio variants to reset timestamp adjustment fixes issues we have with live playback and marked discontinuities, so any fix must still address that issue. The bug here is simple.

1. Demuxed audio rendition playlist is updated, changing the discontinuity sequence (DSN)
2. Next audio segment blocks for timestamps (as a freshly minted `TimestampAdjuster` is picked up)
3. Video fetches continue on a stale DSN / `TimestampAdjuster` (cached version, or just the time ordering of the origin writing the playlists) so playback freezes

Because audio and video are kept in step by the `CompositeSequenceableLoader` (not allowing timeline progress) then playback is frozen forever.

Note the video rendition playlist will update to the new DSN, but the player does not see it.