Long polling/push notifications for new events

Something I've been thinking about for some time is a nice way to get rid of the polling but get patchwork to push events to CI systems when a new series appears.

There are many ways to do it, but one thing is clear: the WSGI protocol is not designed for long TCP connections like Server-sent events (SSE) or websockets. I also don't want a simple "HTTP ping back", ie having patchwork POST the event to a given URL (that the CI system would expose) because that would mean the CI systems need to be accessible by the patchwork instance, instead of being hidden somewhere in a company internal network.

There are two big classes of solutions I see:
- Have a separate daemon handling web sockets/SSE and a way to communicate between the django app and that server (ie patchwork signals the web socket/SSE daemon that forwards the notification to the client). nginx/apache should be able to support proxying that daemon. Two pieces here:
- The daemon itself, could be written in go for instance
- Messaging between the django app and the daemon, redif for instance (I'm considering redis for other features as well)
- There's some interesting uWSGI websocket extension, which locks patchwork in some specific piece of software.
- http://uwsgi-docs.readthedocs.org/en/latest/WebSockets.html

There there's some decision about what kind of communication should go through that event mechanism. It could be what is currently exposed in the `/events/` REST API entry point or a simple notification "there's something new", which client would use to do a HTTP GET on `/events/`.

Related to that, websockets do have the interesting property to be bidirectional, there may be some interesting things we could do with it. For simple push events (and then using the REST API to retrieve detailed information), we don't need websockets.

Related links:
- https://django-websocket-redis.readthedocs.org/en/latest/introduction.html