Fix handling of duplicate packets when OOS data was also received

It's possible for a sequence of packets seqnums like 2, 0, 1, 2 to end up hitting the fast path
again after filling in gap of OOS packets. The fast path assumes duplicate packets are caught
by the next contiguous sequence number check, but this is only true if that value is kept updated.

Since the slow path doesn't update the next contiguous sequence number, it's no longer safe to
use the fast path for the remaining packets in the frame because duplicate packets would be
mishandled.

Queuing duplicate packets violates all sorts of queue assumptions and can cause us to return
corrupt data to the decoder or attempt an FEC recovery without enough shards.

src/RtpVideoQueue.h

@@ -34,6 +34,7 @@ typedef struct _RTP_VIDEO_QUEUE {
     uint32_t fecPercentage;
     uint32_t nextContiguousSequenceNumber;
     uint32_t missingPackets; // # of holes behind receivedHighestSequenceNumber
+    bool useFastQueuePath;
     bool reportedLostFrame;
 
     uint32_t currentFrameNumber;