Implement a custom check (in wpt) for wpt.fyi

[lukebjerring]

Now that we're consuming the output of TaskCluster consistently, we should be building a custom status check for wpt.fyi that is resolved once the results of the run are available for browsing on wpt.fyi.

At a later date, this will tie into a failed status check for any detected regressions.

[lukebjerring]

This diagram loosely describes the flow; currently:

• GitHub pushes status events to /api/webhooks/taskcluster
• TaskCluster eventually pushes its success to GitHub, which in turn notifies wpt.fyi
• wpt.fyi fetches the results from taskcluster

In the future, we'd like the same model for Azure Pipelines, which will involve generalizing /api/webhooks/taskcluster to /api/webhooks/status.

wpt.fyi will create a check_suite for each SHA, and a check_run in the suite for each product run that we learn about (via status updates). The 'create run' endpoint used by the processor will be responsible for following up on the check_run completion.

[lukebjerring]

@Hexcles drew a "timeline" of the to-and-fro, where dashed/dotted lines represent features not yet implemented.

[foolip]

I'd like to add a suggestion here. When full runs from master for the merged commit and the previous merge_pr_* commit are available, a status check on the master commit linking to a diff view would be very useful. Here are examples of where I wanted that view today:
web-platform-tests/wpt#14068 (comment)
web-platform-tests/wpt#14087 (comment)
web-platform-tests/wpt#14088 (comment)

Much of the infrastructure would be the same as we'd use to notice large regressions on master.

@lukebjerring, if you think that's too much scope creep, I'd be happy to file a separate issue.

[foolip]

web-platform-tests/wpt#14094 (comment) too.

[lukebjerring]

Custom checks are now implemented.