Push notifications

The main body of work in this commit is the introduction of push notifications.
A websocket endpoint is available at `/api/push` on which clients can subscribe for activity streams.
So far, no work has been made to make this exensible and support non-activity related features.

Overview
--------

Each app server will have their own transient queue on which it can receive activities.
If the app server dies, this queue and all the activities in it will be removed.

When activities are routed, each one of them will be published to a special exchange `oae-activity-push` with a routing key of `resourceId#activityStreamId`.
This allows us to route activities from the exchange to the app server queues who are interested in those feeds.

When a client connects to a socket he'll end up at an app server. The client will need to subscribe
to certain activityfeeds (his/her activity stream, his/her notification stream, a piece of content's activity stream, ..)
in order to start receiving push notifications for them. When a user subscribes for a feed, the app server will instruct
the message exchange to send all activities for that particular feed to its own queue. When an activity occurs in that feed,
it will end up at the queue, the app server will receive it and then immediately send it out to the client.

In theory, a user will get a push notification as soon as an activity has been routed. Since routing happens as soon as a new
activity has been received from RabbitMQ, this should be very fast.

Refactor work
-------------

Some things had to be refactored in order to support all of the above.

1. Split off task queue functionality from util/MQ into util/TaskQueue
To support the creation of custom queues/routing of messages, the MQ-utility now exposes more direct access to RabbitMQ.
The old functionality is still available in a new utility called `TaskQueue` which is a small wrapper over the `MQ` utility.

2. New activity streams
Activity streams are no longer tied to just `user`s and `group`s, all top-level resources (`content`, `discussion`) can
have their own activity streams.
`activity` and `notification` are also no longer the only supported streams. Users can declare their own streams to which
activities can be routed.
So far the following streams are available:
 * activity
 * notification
 * message (for content comments and discussion messages)

3. Transient routes
Some activity streams don't really need to be persisted to disk (ex: the `message` stream).
When a stream has been marked as transient, its activities will only be emitted after the routing phase and will then be dropped.
These will **NOT** be aggregated.

TODO
----

1. Migration
We will require some migration/transitioning period as activity streams now have slightly different keys.
Use the old activityStreamId in case an activity stream is being request
Cleaned up the MQ utilities.
Push notifications PR follow-up

 * Renamed activityStreamId to streamType in push subscriptions
 * Create utility methods for creating/parsing activity stream IDs
 * Added some jsdoc about the MQ setup
 * Various cleanup in oae-activity/internal/push
Push Notifications follow-up

 * Using `replyTo` for replies to earlier client messages
 * Cleaned and added a bunch of unit tests
 * Added a maximum timeout of 5 seconds. If the client hasn't authenticated by then, their socket will be dropped
Push notifications follow-up

 * Added a `self` propagation
 * Removed `members` association for `discussion-message` and `content-comment`
Fix race-condition in activity test migration test
Merge branch 'master' into simong/push-notifications-sockjs

* master:
  Bumping cassandra to version 1.2.13 for TravisCI
Fleshed out the activity entity transformer

There are now two types of transformers:

 * `activitystreams`
 * `internal`

`activitystreams` returns transformed activity entities that is compliant with the activitystrea.ms spec.
`internal transforms activity entities into their OAE profiles
Follow-up on multiple activity transformers

 * Only pull down unique revisions in the content transformers
 * Cleaned up some comments
Merged master into simong/push-notifiations-sockjs
The transformer type can be selected when subscribing to a Push feed or retrieving data from the REST API.
Get full previews object when transforming content with the internal transformer
Renamed `transformer` to `format` and `transformerType` where appropriate

Also added a check + unit test to ensure that the format gets validated on API/WS requests
getMultipleRevisions requires passing in a dictionary with a `fields` key rather than a string
Added a test that asserts that content-share and content-add-to-library
don't route to the content activity stream
Assert that content-add-to-library and content-share don't end up in the content's activity stream by asserting that the latest one is .
Added a `format` property to the push notification messages
Push - a client should be able to subscribe for the same activity stream twice but with a different format
Added trace log statement when sending out push messages