Server Notices use a special room which the user can't dismiss. They are
created on demand when some other bit of the code calls send_notice.

(This doesn't actually do much yet becuse we don't call send_notice anywhere)

Move RoomCreationHandler out of synapse.handlers.Handlers

Use stream rather depth ordering for push actions

Handlers is deprecated nowadays, so let's move this out before I add a new
dependency on it.

Also fix the docstrings on create_room.

user visit data

ConsentResource to gather policy consent from users

The aim is to keep track of when it was last called and only query from that point in time

Hopefully there are enough comments and docs in this that it makes sense on its
own.

instead of inserting user daily visit data at the end of the day, instead insert incrementally through the day

Part user from rooms on account deactivate

Add a Dockerfile for synapse

Set Server header in SynapseRequest

This simplifies things as it is, but will also allow us to change the
way we traverse topologically without having to update the way push
actions work.

transaction_id, destination defined twice

(instead of everywhere that writes a response. Or rather, the subset of places
which write responses where we haven't forgotten it).

This also means that we don't have to have the mysterious version_string
attribute in anything with a request handler.

Unfortunately it does mean that we have to pass the version string wherever we
instantiate a SynapseSite, which has been c&ped 150 times, but that is code
that ought to be cleaned up anyway really.

Refactor request handling wrappers

This is needless complexity; we might as well use the wrapper directly.

Also rename wrap_request_handler->wrap_json_request_handler.

... so that it can be used on non-JSON endpoints

The metrics are now available via the request, so this is redundant and can go
away at last.

it's much neater there.

less magic

It fits quite nicely here, and opens the path to getting rid of the
"include_metrics" mess.