If someone is using Dendrite and enabling Grafana, we'll no longer
download Synapse dashboards.

If someone is not using node-exporter, we'll no longer download node
exporter dashboards.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2133

This is consistent with what all other roles do. If someone includes a
role, the assumption is that they want its functionality enabled.

The playbook distribution then disables components via
`group_vars/matrix_servers`. We've always had `matrix_grafana_enabled: false`
there, so flipping the in-role `_enabled` flag to `true` does not change
anything for playbook users. Users who import the roles individually in
their own other playbooks (and who don't use `group_vars/matrix_servers`)
may observe a change in the defaults with this.

Using `matrix_synapse_*` variables within the `matrix-grafana` role
is not a good practice.

We now have a `matrix_grafana_default_home_dashboard_path` variable
with a good universal default value and we override it via
`group_vars/matrix_servers` based on enabled components, etc.

This is a better fix for https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2133

We shouldn't be using it in the role (`tasks/setup.yml`) without
defining at least some default value in the role itself.

We've always had the override in `group_vars/matrix_servers`,
so the variable was essentially defined (at the playbook level), but
that's not the right way to do things.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1939

https://grafana.com/docs/grafana/latest/release-notes/release-notes-8-5-1/
https://grafana.com/docs/grafana/latest/release-notes/release-notes-8-5-0/
https://grafana.com/docs/grafana/latest/release-notes/release-notes-8-4-7/
https://grafana.com/docs/grafana/latest/release-notes/release-notes-8-4-6/
https://grafana.com/docs/grafana/latest/release-notes/release-notes-8-4-5/
https://grafana.com/docs/grafana/latest/release-notes/release-notes-8-4-4/
https://grafana.com/docs/grafana/latest/release-notes/release-notes-8-4-3/
https://grafana.com/docs/grafana/latest/release-notes/release-notes-8-4-2/

People often report and ask about these "failures".
More-so previously, when the `docker kill/rm` output was collected,
but it still happens now when people do `systemctl status
matrix-something` and notice that it says "FAILURE".

Suppressing to avoid further time being wasted on saying "this is
expected".

Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1626

Reverts b1b4ba501fdfaa, 90c9801c560b6, a3c84f78ca9c65a, ..

I haven't really traced it (yet), but on some servers, I'm observing
`ansible-playbook ... --tags=start` completing very slowly, waiting
to stop services. I can't reproduce this on all Matrix servers I manage.
I suspect that either the systemd version is to blame or that some
specific service is not responding well to some `docker kill/rm` command.

`ExecStop` seems to work great in all cases and it's what we've been
using for a very long time, so I'm reverting to that.

ExecStopPost should allow us to clean up (docker kill + docker rm)
even if the ExecStart (docker run ..) command failed, and not just after
a graceful service stop was initiated.

Source: https://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStopPost=

https://grafana.com/blog/2021/12/07/grafana-8.3.1-8.2.7-8.1.8-and-8.0.7-released-with-high-severity-security-fix/

Until now, we were leaving services "enabled"
(symlinks in /etc/systemd/system/multi-user.target.wants/).

We clean these up now. Broken symlinks may still exist in older
installations that enabled/disabled services. We're not taking care
to fix these up. It's just a cosmetic defect anyway.

Upgrade grafana (8.1.2 -> 8.1.3)