This is for two reasons:

1. Suppresses duplicates correctly, as the notifier doesn't do any
   duplicate suppression.
2. Makes it easier to connect the AppserviceHandler to the replication
   stream.

login with token (as used by CAS auth) was broken by 067596d3, such that it
always returned a 401.

In the situation where all of a user's devices get deleted, we want to
indicate this to a client, so we want to return an empty dictionary, rather
than nothing at all.

Wrap the `Requester` constructor with a function which provides sensible
defaults, and use it throughout

You can update the displayname of devices now.

Turns out I specced this to return a list of devices rather than a dict of them

implement a GET /devices endpoint which lists all of the user's devices.

It also returns the last IP where we saw that device, so there is some dancing
to fish that out of the user_ips table.

Add a 'devices' table to the storage, as well as a 'device_id' column to
refresh_tokens.

Allow the client to pass a device_id, and initial_device_display_name, to
/login. If login is successful, then register the device in the devices table
if it wasn't known already. If no device_id was supplied, make one up.

Associate the device_id with the access token and refresh token, so that we can
get at it again later. Ensure that the device_id is copied from the refresh
token to the access_token when the token is refreshed.

Fix the relevant unit test cases

Rather than storing them as UserID objects.

* Add infrastructure to the presence handler to track sync requests in external processes

* Expire stale entries for dead external processes

* Add an http endpoint for making users as syncing

Add some docstrings and comments.

* Fixes

Access it directly from the homeserver itself. It already wasn't
inheriting from BaseHandler storing it on the Handlers object was
already somewhat dubious.

Replace flush_user with delete access token due to function removal
Add a new test case for if the user is already registered

 - Add unittests for client, api and handler

Signed-off-by: Negar Fazeli <negar.fazeli@ericsson.com>

This will enable more detailed decisions

Squash-merge of PR #345 from daniel/anonymousevents

I prefer the auth handler to worry about all auth, and register to call
into it as needed, than to smatter auth logic between the two.