Move WPT sync-from-upstream task to Linux

[SimonSapin]

Before this PR, this task keeps one macOS workers busy for many hours every day.

[jdm]

@bors-servo r+

[bors-servo]

📌 Commit 7435f6a has been approved by jdm

[SimonSapin]

Because this task is not used by Homu, testing it requires some manual steps:

• On top of commits destined to go into a PR, make a temporary commit that:
  • Disables irrelevant daily tasks in etc/taskcluster/decision_task.py
  • Disables auto-r+ in etc/ci/update-wpt-checkout
  • Add [Do not merge] in the title of the PR created by etc/ci/update-wpt-checkout
• Go to https://community-tc.services.mozilla.com/hooks/project-servo/daily
• Click on one of the task IDs under "Last Fired Attempts"
• Click on "View task definition"
• Copy that JSON blob
• Go to https://community-tc.services.mozilla.com/tasks/create
• Paste the JSON blob in the editor
• Click on "Update timestamps" in the bottom-right menu. This also reformats the definition to JSON.
• Edit GIT_REF in the task definition to use the branch pushed previously.
• Click the "Create task" button at the bottom left
• Wait 3 to 4 hours

The first attempt (that didn’t fail) resulted in #25086, which looks similar to #25077 which ran on macOS around the same time. Both PRs change many files, presumably because upstream WPT had many changes since the last sync.

To eliminate that source of change, #25115 was made by another run that also disabled syncing from upstream WPT. It touches 54 .ini file. That number would be zero if Servo was perfectly deterministic and behaved the same on Linux v.s. macOS.

I’ve started another run with the same configuration to see if the results look different. jdm says on IRC that those 54 are plausibly all due to intermittent test results, though.

[SimonSapin]

Uh, it looks like https://github.com/servo/servo/pull/25115/files may have been overwritten by the actual daily task (since the branch name is based only on the date.) Anyway, 5aa458e in #25122 also changes 53 .ini files and looks similar to my (vague) memory of the other diff.

If some of these are deterministic but due to differences between Linux and macOS, do we risk having macOS CI start failing after a PR like this is merged? @jdm, what do you think?

[jdm]

I don't see how it's any different from the current situation - linux CI has to pass for any new sync PR when the mac machines generate them, this is just the reverse. I think this is fine.

[bors-servo]

⌛ Testing commit 7435f6a with merge 250184f...

[bors-servo]

☀️ Test successful - status-taskcluster
Approved by: jdm
Pushing 250184f to master...