Set and adopt naming policy for bridges

[luixxiul]

Describe the bug

Currently there is not a consistent policy about naming variables and files for bridges on the playbook, and they often contradict each other.

See #4695:

There is not a consistent pattern at all as far as I see:

* matrix-bridge-heisenbridge: `matrix_heisenbridge_*`

* matrix-bridge-hookshot: `matrix_hookshot_*`

* matrix-bridge-steam: `matrix_steam_bridge_*`

I would change them into what's based on a hierarchy:

* matrix-bridge-heisenbridge: `matrix_bridge_heisenbridge_*` (we won't set it to `matrix_bridge_heisen_*` as "heisenbridge" is the name of the bridge)

* matrix-bridge-hookshot: `matrix_bridge_hookshot_*`

* matrix-bridge-steam: `matrix_bridge_steam_*`

Regarding to matrix-bridge-zulip, it seems confusing to switch the place of "bridge" and "zulip" like matrix_zulip_bridge_* against the name of the bridge itself, which respects the hierarchy (despite there being some exceptions like matrix-sms-bridge).

The bridge for Steam is named as matrix-steam-bridge simply because it is the same as the same of the bridge itself (see: https://github.com/jasonlaguidice/matrix-steam-bridge).

If matrix-bridge-heisenbridge variables are set to matrix_bridge_heisenbridge_*, the variables for this bridge should be set to matrix_bridge_matrixzulipbridge_* if we respect the hierarchy for the sake of predictability.

Still, it is a completely different theme, and should definitely be addressed on another occasion.

The playbook has become well matured, and I do not think a new bunch of services will be implemented like ever, but lack of naming policy for file names and variable names is the tech burden which slows down the development work and harms maintainability anyway.

To Reproduce

Expected behavior

• Consistent naming policy to be applied for bridges
• Respect the path name and use it for anything inside the path

There is a pretty good example on the playbook such as matrix-client-cinny, where variable names and file names are nicely sync'd and predictability is high. File names and variable names for bridges can adopt the pattern over there as example.

For example, if the service is named as matrix-bridge-zulip, then the files should be named as matrix-bridge-zulip* and the variables as matrix_bridge_zulip_*.

• 👍
  • matrix_bridge_zulip_enabled
  • matrix-bridge-zulip.service.j2
  • ...
  • matrix_client_cinny_enabled (this exists)
  • matrix-client-cinny.service.j2 (this exists)
• 👎
  • matrix_zulip_bridge_enabled
  • matrix-zulip-bridge.service.j2
  • ...
  • matrix_cinny_client_enabled (this does not exist)
  • matrix-cinny_client.service.j2 (this does not exist)

Matrix Server:

Ansible:

Additional context

[luixxiul]

There are other cases where naming policy for file names is nonexistent, such as matrix-registration, matrix-sygnal, etc.

Though they should be addressed as well, the low hanging fruit here is to address something whose hierarchy is well clear, which is bot, bridges, and homeservers. What does not have a higher category can be ignored for a while, unless we create one for them by any chance.

Let's fix from what can be fixed easily.