OffscreenCanvas API
<!-- Please describe your changes on the following line: -->
Initial Steps for OffscreenCanvas API are done in this commit.
r? @jdm
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#14627 (GitHub issue number if applicable)
<!-- Either: -->
- [X] There are tests for these changes OR
- [ ] These changes do not require tests because ___
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/22495)
<!-- Reviewable:end -->
Implement step 6 of media `time marches on` algorithm. Improves stability of media WPTs
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] There are tests for these changes
This should help with the WPTs problems observed in https://github.com/servo/servo/pull/22348#issuecomment-446369831
Unfortunately, GStreamer does not seem to be very reliable with Ogg (check https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/520) and most of the media-element WPTs uses a short ogv file, so I had to make our `canPlayType` report that it is not able to play this type to make the tests pick the alternative mp4 version of the same files. Once Ogg support for GStreamer improves, we should be able to revert this change.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/22477)
<!-- Reviewable:end -->
script: Implement the HTMLTrackElement API
Implement the basics of the HTMLTrackElement and update the wpt tests.
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] There are tests for these changes
Fixes: https://github.com/servo/servo/issues/22313
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/22563)
<!-- Reviewable:end -->
Implement source for postMessage events
Also make similar-origin iframes access their newly loaded document as soon as the new document is created. This should allow tests that check the event.source property to run correctly.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#22499 and fix#12715 and fix#22514.
- [x] There are tests for these changes
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/22514)
<!-- Reviewable:end -->
Improve implementation of media resource fetch algorithm
I have been observing inconsistent behaviors with my local tests depending of the media asset being played. I figured that we had these issues:
- We were setting the player EOS as soon as we got the first [process_response_eof](1046ae58a1/components/script/dom/htmlmediaelement.rs (L1596)). This is fine only if there is a single request. But that's not the case for multiple range requests or for seeks. Setting the player EOS makes the player appsrc reject any new buffers, and that breaks playback. Figuring out when is the right time to set the player EOS won't be a straight forward task, so my suggested fix for now is to simply not set it for now. It is a cleanup step that it would be nice to have but it is not mandatory.
- We were setting the input size more than once for multiple range requests and with the incorrect value. The fix uses the `content-length` or the `content-range` headers for single and range requests respectively.
- We were moving to the HaveEnoughData state if a fetch request succeded but no data was fetched from the network.
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/22433)
<!-- Reviewable:end -->
