Don't redeliver received keyframes after seq num discontinuity

RtpVideoStreamReceiver2 ends a large sequence number discontinuity at a
keyframe with an RTP timestamp newer than the newest received media, but
took that timestamp from the packet with the newest sequence number. A
packet with a high sequence number and an old timestamp could thus make
an already received keyframe look new. A copy of that keyframe far
behind in sequence numbers then reset the receiver and was decoded a
second time under a new frame id. Track the newest media RTP timestamp
independently of the sequence number instead.

Decoding two frames with the same RTP timestamp before either is
rendered also hit a DCHECK in VideoQualityObserver::OnDecodedFrame. The
timestamp is set by the remote sender, so this is reachable without the
recovery logic too, e.g. with two keyframes that share a timestamp.
Remove the DCHECK; caching a blocky timestamp twice is harmless.

Bug: chromium:568946767
Change-Id: I905de47bd32806ad792e381b1139592fed9477f7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/507641
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#48804}