Multiple gecko backouts

[moz-servo-sync]

Backed out changeset a417b9d7712d for vendoring bustage. r=backout on a CLOSED TREE

Backs out #17565

---

This change is 

---

Backed out changeset c424ad1c5f94 for build failures a=backout CLOSED TREE

Backs out #17892

[moz-servo-sync]

@bors-servo r+ force p=9001 treeclosed=9000

[bors-servo]

📌 Commit f022936 has been approved by moz-servo-sync

[highfive]

Thanks for the pull request, and welcome! The Servo team is excited to review your changes, and you should hear from @Manishearth (or someone else) soon.

[highfive]

Heads up! This PR modifies the following files:

• @aneeshusa: etc/ci/buildbot_steps.yml
• @fitzgen: components/script/dom/servoparser/async_html.rs
• @KiChjang: components/script/dom/servoparser/async_html.rs

[highfive]

Warning

• These commits modify unsafe code. Please review it carefully!
• These commits modify script code, but no tests are modified. Please consider adding a test!

[jdm]

@bors-servo: treeclosed-

[bors-servo]

⌛ Testing commit f022936 with merge 2dfb22c...

[jdm]

@bors-servo: treeclosed=9000

[moz-servo-sync]

@bors-servo r+ force p=9001 treeclosed=9000

[bors-servo]

💡 This pull request was already approved, no need to approve it again.

• This pull request is currently being tested. If there's no response from the continuous integration service, you may use retry to trigger a build again.

[bors-servo]

📌 Commit 3f1af3e has been approved by moz-servo-sync

[KiChjang]

@bors-servo treeclosed-

[bors-servo]

⌛ Testing commit 3f1af3e with merge ef2d48d...

[KiChjang]

@bors-servo treeclosed=9000

[upsuper]

So #17565 is probably innocent, and #17892 is gulity for the bustage on Gecko tree.

The reason is that #17892 makes style_traits depend on webrender, while Gecko already has a webrender vendored in another place in the tree, which causes this problem.

I'm not sure what should we do here.

There are two potential solutions:

1. Split the types into an independent crate, and put it on crates.io, so that webrender and style_traits can share the crate, and Gecko can vendor the new crate as a third_party.
2. Have Gecko not vendor webrender directly, but make webrender a third_party.

Both of them have drawbacks, though.

For the first one, it means updating that crate would take more effort. If those types aren't updated frequently, this might be the best solution.

For the second one, I suppose it would make development harder for Quantum Render project, because third_party is not mutable in Gecko, so they would not be able to update code simultaneously without more complicated setup. It would make it much like how Stylo project looks like before we vendor Servo into Gecko tree.

[bors-servo]

☀️ Test successful - android, arm32, arm64, linux-dev, linux-rel-css, linux-rel-wpt, mac-dev-unit, mac-rel-css1, mac-rel-css2, mac-rel-wpt1, mac-rel-wpt2, mac-rel-wpt3, mac-rel-wpt4, windows-msvc-dev
Approved by: moz-servo-sync
Pushing ef2d48d to master...

[upsuper]

Oh, it seems #17908 is for resolving the problem of #17892.