Implement a SystemMessage model

The model represents messages emitted by the system into chat rooms.
These messages are to be various status messages, such as a notification
that a user has left or joined the chat room.

The class makes sure the system is extensible enough to support any
kind of system-generated message in the future.
Add a custom manager for system messages

The custom manager offers convenience methods for creating the most
used system messages. For now those are the user joined/left
notifications.
Create member joined notifications

When a member is added to a chat room, an appropriate notification
system-level message is created in the chat room.

There are no push-notifications sent for such a message though.
Merge branch 'feature/user-joined-left-messages'
Add a mixin class providing signature validation

It can be mixed in to api view classes which want to check for
signature validity.
Implement member-based signature validation

The member based signature validation extends the signature validation
mixin to use values which are expected when validating messages sent
by the TCA Chat members.

This means that:

 - The message which is to be validated is always that member's lrz_id
 - The public keys to be used for validation are always the keys
   associated with a particular member
Validate requests to join a chat room by checking the signature

This is achieved by mixing in the member-based signature validation
to the appropriate view.
Make sure the crypto.verify function acts as expected for None params

If a client passes ``None`` as one of the parameters to the function,
the signature cannot be considered valid, so make sure that is the
result that is returned (not True and not an exception)
Add tests making sure invalid requests don't trip up add_member
Refactor registration ID views

Simplify getting the member associated to the request to accessing
a property, instead of having to call a method.

The property is a django-provided cached_property to avoid querying
the database each time the property is referenced
Refactor registration ID views to use a common base class

The fact that they were using a mixin does not make too much sense
from a design perspective (and is a remnant of an earlier approach
which did not survive)
Validate signature for adding/removing registration IDs

Adding or removing a registration ID for a particular member should
also be subject to signature-verification-based authorization.
Merge branch 'feature/signature-auth'
Add asserts that the add/remove registration ids are validated
Implement leaving a chat room

A user can leave a chat room by submitting a POST request to the
/chat_rooms/:id/remove_member endpoint.  The request consists of a
JSON payload with the following format::

    {
        "lrz_id": "id_to_remove",
        "signature": "signature for the request signing their lrz_id"
    }

If the attached signature is not valid, the server will respond with a
403 Forbidden status code and not allow the removal of the member, so
as to avoid unauthorized removal from the chat room.