This keeps the roles cleaner and more independent of matrix-base,
which may be important for people building their own playbook
out of the individual roles and not using the matrix-base role.

Regression since #362 (Github Pull Request).

Synapse v1.9.0 changed some things which made the REST Auth Password
Provider break.

The ma1uta/matrix-synapse-rest-password-provider implements some
workarounds for now and will likely deliver a proper fix in the future.

Not much has changed between the 2 projects, so this should be a
painless transition.

Related to #355.

Can you double check that the way I have this set only exposes it locally? It is important that the manhole is not available to the outside world since it is quite powerful and the password is hard coded.

Prompted by: https://matrix.org/blog/2019/11/09/avoiding-unwelcome-visitors-on-private-matrix-servers

This is a bit controversial, because.. the Synapse default remains open,
while the general advice (as per the blog post) is to make it more private.

I'm not sure exactly what kind of server people set up and whether they
want to make the room directory public. Our general goal is to favor
privacy and security when running personal (family & friends) and corporate
homeservers, both of which likely benefit from having a more secure default.

Don't mention systemd-journald adjustment anymore, because
we've changed log levels to WARNING and Synapse is not chatty by default
anymore.

The "excessive log messages may get dropped on CentOS" issue no longer
applies to most users and we shouldn't bother them with it.

Fixes #255 (Github Issue).

This only gets triggered if:
- the Synapse role is used standalone and the default values are used
- the whole playbook is used, with `matrix_mxisd_enabled: false`

Also discussed previously in #213 (Github Pull Request).

shared-secret-auth and rest-auth logging is still at `INFO`
intentionally, as user login events seem more important to keep.
Those modules typically don't spam as much.