This is based on the PR (https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3241)
by Tobias Diez (https://github.com/tobiasdiez).

I've refactored some parts, made it more configurable, polished it up,
and it's integrated into the playbook now.

Both the WeChat bridge and WeChat agent appear to be working.
The WeChat bridge joins rooms and responds as expected.

That said, end-to-end testing (actually bridging to a WeChat account) has not been done yet.

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

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

This is sponsored https://etke.cc/ work related to https://gitlab.com/etke.cc/ansible/-/issues/2

Squashed commit of the following:

commit fdd37f0247
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Mon Jun 3 21:05:53 2024 +0300

    Add documentation for WeChat bridge

commit 8426fc8b95
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Mon Jun 3 20:59:42 2024 +0300

    Rename directory for matrix_wechat_agent_container_src_files_path

commit da200df82b
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Mon Jun 3 20:58:26 2024 +0300

    Make WeChat listen_secret configurable and auto-configured via matrix_homeserver_generic_secret_key

commit 4022cb1355
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Mon Jun 3 20:54:56 2024 +0300

    Refactor install.yml for WeChat a bit (using blocks, etc.)

commit d07a39b4c4
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Mon Jun 3 20:52:35 2024 +0300

    Rename WeChat Agent configuration file

    This makes it more clear that it belongs to the agent.
    Otherwise, `config.yaml` and `configure.yaml` make you wonder.

commit ccca72f8d1
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Mon Jun 3 20:49:06 2024 +0300

    Move WeChat agent configuration to a template

commit a4047d94d8
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Mon Jun 3 20:47:17 2024 +0300

    Mount WeChat config as readonly and instruct bridge to not update it

commit bc0e89f345
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Mon Jun 3 20:46:33 2024 +0300

    Sync WeChat config with upstream

    Brings up-to-date with:
    https://github.com/duo/matrix-wechat/commits/0.2.4/example-config.yaml

commit a46f5b9cbc
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Mon Jun 3 19:48:17 2024 +0300

    Rename some files

commit 3877679040
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Mon Jun 3 19:47:10 2024 +0300

    Update WeChat logging config

    This brings it up-to-date with what mautrix-go uses.
    Otherwise, on startup we see:

    > Migrating legacy log config

    .. and it gets migrated to what we've done here.

commit e3e95ab234
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Mon Jun 3 19:43:37 2024 +0300

    Make sure matrix-wechat-agent runs as 1000:1000

    It needs to write stuff to `/home/user/.vnc`.

    `/home/user` is owned by `user:group` (`1000:1000`), so it cannot run
    any other way.

    Previously, if the `matrix` user was uid=1000 by chance, it would work,
    but that's pure luck.

commit 4d5748ae9b
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Mon Jun 3 18:57:09 2024 +0300

    Pin wechat and wechat-agent versions

commit 40d40009f1
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Mon Jun 3 18:53:58 2024 +0300

    docker_image -> container_image for WeChat bridge

commit cc33aff592
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Mon Jun 3 18:00:25 2024 +0300

    docker_src -> container_src in WeChat bridge

commit 42e6ae9a64
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Mon Jun 3 17:54:24 2024 +0300

    matrix_go_wechat_ -> matrix_wechat_

    The bridge is written in Go, but does not include Go anywhere in its
    name. As such, it's mostly useless to use `matrix_go_wechat` as the
    prefix.

commit d6662a69d1
Author: Tobias Diez <code@tobiasdiez.de>
Date:   Mon Mar 25 10:55:16 2024 +0800

    Add wechat bridge

This allows people to try out the new Element X clients, which need to
run against the sliding-sync proxy (https://github.com/matrix-org/sliding-sync).

Supersedes https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2515

The code is based on the existing PR (#2515), but heavily reworked. Major changes:

- lots of internal refactoring and variable renaming

- fixed self-building to support non-amd64 architectures

- changed to talk to the homeserver locally, over the container network (not
  publicly)

- no more matrix-nginx-proxy support due to complexity (see below)

- no more `matrix_server_fqn_sliding_sync_proxy` in favor of
  `matrix_sliding_sync_hostname` and `matrix_sliding_sync_path_prefix`

- runs on `matrix.DOMAIN/sliding-sync` by default, so it can tried
  easily without having to create new DNS records

This container needs a writable $HOME, and will fail at startup if
there isn't one.

Provide one by pointing HOME to a path under the mounted /data
directory.

Co-Authored-By: Slavi Pantaleev <slavi@devture.com>

This paves the way for installing other roles into `roles/galaxy` using `ansible-galaxy`,
similar to how it's done in:

- https://github.com/spantaleev/gitea-docker-ansible-deploy
- https://github.com/spantaleev/nextcloud-docker-ansible-deploy

In the near future, we'll be removing a lot of the shared role code from here
and using upstream roles for it. Some of the core `matrix-*` roles have
already been extracted out into other reusable roles:

- https://github.com/devture/com.devture.ansible.role.postgres
- https://github.com/devture/com.devture.ansible.role.systemd_docker_base
- https://github.com/devture/com.devture.ansible.role.timesync
- https://github.com/devture/com.devture.ansible.role.vars_preserver
- https://github.com/devture/com.devture.ansible.role.playbook_runtime_messages
- https://github.com/devture/com.devture.ansible.role.playbook_help

We just need to migrate to those.

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".

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.