Update rtpStream->maxPacketTs in a specific scenario

[oppolixiang]

i found this issue when i test a long video conference.
once i lock the screen, the producer will not send any rtp packet, for example, the last rtp packet timestamp is 1000000000, seq is 100.
after a night, i unlock the screen and the producer start to send rtp packet seq 101 、102 、103。but their timestamp maybe lower then the packet of seq 100(cause of a ts reverse), for example 100000000.

in this condition ,if the consumer nack for the packet 101, FillRetransmissionContainer will calcarate the diffMs>2000ms then consumer nack will become invalid for a long while. (in this case, the calculation of the diffMs may also be inaccurate).
diffMs = diffTs * 1000 / this->params.clockRate; ==> diffMs = diffTs / (this->params.clockRate/1000);

should update rtpStream->maxPacketTs of RtpStreamRecv and RtpStreamSend in this scenario.

bool RtpStream::UpdateSeq(RTC::RtpPacket* packet)
{
	MS_TRACE();

	uint16_t seq    = packet->GetSequenceNumber();
	uint16_t udelta = seq - this->maxSeq;

	// If the new packet sequence number is greater than the max seen but not
	// "so much bigger", accept it.
	// NOTE: udelta also handles the case of a new cycle, this is:
	//    maxSeq:65536, seq:0 => udelta:1
	if (udelta < MaxDropout)
	{
		// In order, with permissible gap.
		if (seq < this->maxSeq)
		{
			// Sequence number wrapped: count another 64K cycle.
			this->cycles += RtpSeqMod;
		}

		this->maxSeq = seq;

		// ts reverse with in order seq.(cause by producer inactive for a long time(for example a night))
		if (RTC::SeqManager<uint32_t>::IsSeqLowerThan(packet->GetTimestamp(), this->maxPacketTs))
		{
			MS_WARN_TAG(rtp, "update RtpStream maxPacketTs old %u new %u", this->maxPacketTs, packet->GetTimestamp());
			this->maxPacketTs = packet->GetTimestamp();
			this->maxPacketMs = DepLibUV::GetTimeMs();
		}
	}
}

[ibc]

Can this be reproducible with a worker test?