videorate: Segment update regressions

There are a couple of regressions with segment updates that were introduced in gst-plugins-base!767 (merged) .

CC @ocrete

This MR adds a test for the first one for which I could produce a test. I'll add tests for the other ones once I have them.

---

First problem

First test starts with a [0s,-1] segment and handles some buffers, then moves to a [30s,-1] segment. videorate considers this as a segment update and does not drain out the previous buffer <30s. Which then causes it to output the previous with a duration of almost 30s and completely wrong running time, and from then on every gets confused.

I don't know what the expected behaviour here would be but I think videorate should detect this not as a "segment update" but rather as a "new segment", drain out old buffers and then continue with the next segment.

Input is

N| PTS              | duration        |
1: 0:00:00.000000000 0:00:00.040000000
2: 0:00:00.040000000 0:00:00.040000000
3: 0:00:00.080000000 0:00:00.040000000
----- segment here -----
4: 0:00:30.040000000 0:00:00.040000000
5: 0:00:30.080000000 0:00:00.040000000

These are the buffers being output here

N| PTS              | duration        |
1: 0:00:00.000000000 0:00:00.040000000
2: 0:00:00.040000000 0:00:00.040000000
----- segment here -----
5: 0:00:30.080000000 0:00:30.040000000

This is clearly wrong. Buffers 3/4 are completely gone and buffer 5 has a duration of 30s instead of 40ms.

Before the MR the behaviour was to just output the buffers as they were input, but to have a 4: 0:00:30.000000000 0:00:00.040000000 duplicated buffer to fill the small gap after the segment.

The expected behaviour here is probably not to fill 30s of duplicated frames but like before the MR.

---

Second problem

First segment is [30s,-1] and a few buffers are passed through that are inside this segment. Then the same [30s,-1] segment is sent again and some more buffers with increasing timestamps inside the segment are passed through. And this duplicated segment event is confusing the output around the segment event completely.

Input is

1: 0:00:32.000000000 0:00:00.040000000
2: 0:00:32.040000000 0:00:00.040000000
3: 0:00:32.080000000 0:00:00.040000000
---- segment here ----
4: 0:00:35.040000000 0:00:00.040000000
5: 0:00:35.080000000 0:00:00.040000000

Output here is

1: 1 0:00:30.000000000 0:00:00.040000000
[...]
1: 0:00:32.000000000 0:00:00.040000000
2: 0:00:32.040000000 0:00:00.040000000
---- segment here ----
3: 0:00:32.080000000 5124095:34:31.669551616
3: 0:00:30.040000000 0:00:00.040000000
[...]
3: 0:00:33.560000000 0:00:00.040000000
4: 0:00:33.600000000 0:00:00.040000000
[...]
4: 0:00:35.040000000 0:00:00.040000000
5: 0:00:35.080000000 0:00:00.040000000

This is of course also completely wrong. There is a negative duration, timestamps are going backwards for no reason, the segment event is forwarded at the wrong place.

The old behaviour before the MR was to have a gap between 3: 0:00:32.080000000 0:00:00.040000000 and 4: 0:00:35.040000000 0:00:00.040000000, which seems fine. But filling that gap could also be a valid behaviour, I guess.