* ensure can report mau stats when hs.config.mau_stats_only is set

Allow for the creation of a support user.

A support user can access the server, join rooms, interact with other users, but does not appear in the user directory nor does it contribute to monthly active user limits.

* Improved static/index.html look, feel and content.

* Added accessibility tags to in-line SVG.

* Grammar.

Update link to kernel.org DCO usage

Reduce size of hyperlink

Stop installing Matrix Console by default

Add a welcome page to the static resources

Disable pager for ci script

... otherwise it hangs

This is largely a precursor for the removal of the bundled webclient. The idea
is to present a page at / which reassures people that something is working, and
to give them some links for next steps.

The welcome page lives at `/_matrix/static/`, so is enabled alongside the other
`static` resources (which, in practice, means the client API is enabled). We'll
redirect to it from `/` if we have nothing better to display there.

It would be nice to have a way to disable it (in the same way that you might
disable the nginx welcome page), but I can't really think of a good way to do
that without a load of ickiness.

It's based on the work done by @krombel for #2601.

This is based on the work done by @krombel in #2601.

* Add 'sandbox' to the CSP for media repo

* Changelog

Make /config more CORS-y

Make isort tox check print diff when it fails

https://www.kernel.org/doc/Documentation/SubmittingPatches returns a simple page indicating that it's moved to: "process/submitting-patches.rst".

I believe the new link contains the same information as what was previously linked to.

When we register a new user from SAML2 data, initialise their displayname
correctly.

If you're installing as a system package, the system package should have set up
the systemd config, so it's more useful to give an example of running in a
virtualenv here.

This implements both a SAML2 metadata endpoint (at
`/_matrix/saml2/metadata.xml`), and a SAML2 response receiver (at
`/_matrix/saml2/authn_response`). If the SAML2 response matches what's been
configured, we complete the SSO login flow by redirecting to the client url
(aka `RelayState` in SAML2 jargon) with a login token.

What we don't yet have is anything to build a SAML2 request and redirect the
user to the identity provider. That is left as an exercise for the reader.

This is mostly factoring out the post-CAS-login code to somewhere we can reuse
it for other SSO flows, but it also fixes the userid mapping while we're at it.

* Rip out half-implemented m.login.saml2 support

This was implemented in an odd way that left most of the work to the client, in
a way that I really didn't understand. It's going to be a pain to maintain, so
let's start by ripping it out.

* drop undocumented dependency on dateutil

It turns out we were relying on dateutil being pulled in transitively by
pysaml2. There's no need for that bloat.

It turns out we were relying on dateutil being pulled in transitively by
pysaml2. There's no need for that bloat.

Sometimes it's useful for synapse to generate its own .well-known file.