Transition Travis CI webhook token to webhook signatures

[nastevens]

See https://blog.travis-ci.com/2016-08-31-webhook-delivery-changes

Using the GitHub Token field for authorizing webhook requests is being replaced with a public/private signing infrastructure, with the old method being removed November 1st. Presumably that would mean that homu instances using the token method with Travis CI would cease to function on that date.

The new authorizing webhook actually simplifies things as a special token will no longer be required for repos connecting with a homu server.

[Manishearth]

cc @larsbergstrom

I was considering removing the special travis handling entirely, and solely using status notifications.

[larsbergstrom]

@Manishearth I've seen a few cases where homu seems to get very confused (in particular, pre-approving things that have not been approved yet) reading GitHub status notifications, though I haven't tracked it all down yet. There's also currently a failure handling GitHub status notifications that is breaking the Servo homu right now (this morning), so I might want to wait and figure out what's going on with these issues before removing that fallback support.

I suspect that getting the notifications directly from travis is going to be more reliable than bouncing them through via GitHub, but I could be wrong here.

[Manishearth]

agreed

[nastevens]

Looking at the examples from the Travis blog post, it doesn't seem like it would be that much effort to integrate the new signatures in place of the token. If I had some time to look at integrating, would that be useful? Or is the thought that removing the Travis dependency entirely is the way forward?

[cgwalters]

My vote is nuke the Travis-specific code. The architecture becomes clearer in that case.

[Manishearth]

Eventually I'd like to remove the travis-specific stuff and focus on webhooks, though that's gated on webhooks working as expected (as Lars said, that's not necessarily the case at the moment, and we've had issues with this before).

But for now it seems like the way to go forward is to change the code that handles the /travis route