Continue waiting for keys until the codec is flushed.

It was possible for a codec input buffer to be filled with two frames' worth of
data, if seekTo was called after populating a buffer, if waitingForKeys was true
and seeking did not trigger a flush. This caused the CryptoInfo to be configured
as if the input buffer contained a large amount of reconfiguration data as
cleartext.

Move resetting waitingForKeys to flushCodec, so that we don't try to read the
next sample from the source until the first one has been consumed or discarded.

library/src/main/java/com/google/android/exoplayer/MediaCodecTrackRenderer.java

@@ -370,6 +370,7 @@ public abstract class MediaCodecTrackRenderer extends TrackRenderer {
       codecHotswapTimeMs = -1;
       inputIndex = -1;
       outputIndex = -1;
+      waitingForKeys = false;
       decodeOnlyPresentationTimestamps.clear();
       inputBuffers = null;
       outputBuffers = null;
@@ -418,7 +419,6 @@ public abstract class MediaCodecTrackRenderer extends TrackRenderer {
     sourceState = SOURCE_STATE_NOT_READY;
     inputStreamEnded = false;
     outputStreamEnded = false;
-    waitingForKeys = false;
   }
 
   @Override
@@ -478,6 +478,7 @@ public abstract class MediaCodecTrackRenderer extends TrackRenderer {
     inputIndex = -1;
     outputIndex = -1;
     waitingForFirstSyncFrame = true;
+    waitingForKeys = false;
     decodeOnlyPresentationTimestamps.clear();
     // Workaround for framework bugs.
     // See [Internal: b/8347958], [Internal: b/8578467], [Internal: b/8543366].