Test MediaRecorder-blob-timecode.https.html test a particular implementation

[jyavenard]

wpt/mediacapture-record/MediaRecorder-blob-timecode.https.html

Line 30 in 8686b7a

assert_greater_than(timecode, previous_timecode, "timecode must increase monotonically");

The test create a MediaRecorder with a timeslice of 0.

Per spec

If timeslice is not undefined, then once a minimum of timeslice milliseconds of data have been collected, or some minimum time slice imposed by the UA,
whichever is greater, start gathering data into a new [Blob](https://w3c.github.io/FileAPI/#dfn-Blob) blob, and queue a task, using the DOM manipulation task source, that [fires a blob event](https://w3c.github.io/mediacapture-record/#fire-a-blob-event)
named [dataavailable](https://w3c.github.io/mediacapture-record/#eventdef-mediarecorder-dataavailable) at recorder with blob.
Note that an undefined value of timeslice will be understood as the largest unsigned long value.

If the UA doesn't have a minimum time slice (from a quick search it appears that only Blink does), then the UA could emit an empty blob or a blob that contains no actual data, and as such the timecode will not increase. This would cause the test to fail, even though it's technically correct.

as:

Let blob be the [Blob](https://w3c.github.io/FileAPI/#dfn-Blob) of collected data so far and let target be the [MediaRecorder](https://w3c.github.io/mediacapture-record/#mediarecorder) context object,
then [fire a blob event](https://w3c.github.io/mediacapture-record/#fire-a-blob-event) named [dataavailable](https://w3c.github.io/mediacapture-record/#eventdef-mediarecorder-dataavailable) at target with blob.
(Note that blob will be empty if no data has been gathered yet.)

Blink uses a minimum of 1s for mp4
https://source.chromium.org/chromium/chromium/src/+/main:media/muxers/mp4_muxer.cc;l=16;drc=0afc9ac9afcaab79fc54299039f4d27abf3a086d (comment is wrong there btw it states 10Hz)
and 100ms for webm
https://source.chromium.org/chromium/chromium/src/+/main:media/muxers/webm_muxer.cc;drc=08f8d54d5ac60fcbb3d072dd9b41696579dbcecd;bpv=1;bpt=1;l=75

[jyavenard]

@cpsgchue

[jyavenard]

This test had the benefit of exposing some issues, at least in the cocoa rewrite.

For the test to pass, I've made it that we will not emit dataavailable if the call to MediaRecorderPrivate::fetchData() was due to the timeslice and no data was returned. It makes more sense IMHO than to say dataavailable and yet nothing new was added.
if the site calls requestData() dataavailable will still be emitted.

In the cocoa writer, if the timeslice was small enough, it would force a flush of the audio when the compressor was still emitting frames with no audible content (due to encoder delay), on the next call we would write the next audible audio sample (which still had the same timestamp as all the others) and caused the AVAssetWriter to error.. I also limited the size of the segment written to be 1s, otherwise the AVAssetWriter would report "not ready"