Ensure payload type frequency does not cause divide-by-zero

This CL does 2 things:
- Change the DCHECK for payload_type_frequency to a CHECK (so that
this error will be a crash not a divide-by-zero)
- Change the replay helper that was used by the fuzzer to set the
frequency of the packets to the video value (90K).

Bug: chromium:1466826
Change-Id: I39941f250b1782b36a3bcddfd347a016591466ec
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/312700
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40468}

modules/rtp_rtcp/source/receive_statistics_impl.cc

@@ -319,7 +319,7 @@ bool StreamStatisticianImpl::IsRetransmitOfOldPacket(
     Timestamp now) const {
   int frequency_hz = packet.payload_type_frequency();
   RTC_DCHECK(last_receive_time_.has_value());
-  RTC_DCHECK_GT(frequency_hz, 0);
+  RTC_CHECK_GT(frequency_hz, 0);
   TimeDelta time_diff = now - *last_receive_time_;
 
   // Diff in time stamp since last received in order.

test/fuzzers/utils/rtp_replayer.cc

@@ -187,6 +187,8 @@ void RtpReplayer::ReplayPackets(
       RTC_LOG(LS_ERROR) << "Packet error, corrupt packets or incorrect setup?";
       break;
     }
+    // Set the clock rate - always 90K for video
+    received_packet.set_payload_type_frequency(kVideoPayloadTypeFrequency);
 
     call->Receiver()->DeliverRtpPacket(
         MediaType::VIDEO, std::move(received_packet),