docs: add missing packages and improve wifi configuration

[maurerle]

I hope that these changes are not too controversial.. :)

• add docs on building docs
• add docs for gluon-mesh-vpn-sqm
• add docs for gluon-wireless-encryption-wpa3
• improve section on wireless roles
• improve docs to layer3 multicast setup from @T-X

closes #3131

[T-X]

Many thanks for the work, for a voluntary community project it's so important to have good documentation, to understand but also to allow others to jump in if needed.

For the SQM package I was wondering, does it "only" reduce latency / bufferbloat? Or could it also enable some fairness between streams? For example in a setup with three fully meshed nodes A, B, C, and C provides an uplink via fastd: Would each client device / client MAC address on A and B get the same bandwidth over the fastd tunnel? Or is that not possible yet, because CAKE is not capable to look inside the batman-adv header? (But could maybe also be discussed or added later, don't want to derail this PR.)

[neocturne]

There are still a few unresolved comments (2 of which Github had helpfully hidden...) - and I just unresolved one that I consider important. We can merge this after everything has been resolved and backport to 2025.1.x later.

[maurerle]

The open discussions are fixed now - so this should be good.

[neocturne]

This does not work. The venv must not be located inside the docs directory, or Sphinx will attempt to build parts of the venv as doc files.

[neocturne]

Also, using . instead of source is preferable, as it is compatible with more shells (. is POSIX shell, while source is a bash extension supported by many, but not all shells)

[neocturne]

Choosing a path like .venv and adding it to exclude_patterns in conf.py and .gitignore would be an option. Might just call it venv though, no need to hide it.

[maurerle]

I changed instructions to create the venv in the repo root - what do you think about this?

[neocturne]

This is how I've been building the docs usually, but it may be cleaner to provide a way to keep the venv in the docs directory (may also reduce confusion if we ever add another requirements.txt for a separate Python environment) - as mentioned, this would just require adding the designated venv directory to exclude_patterns.

Maybe _venv would be a good name then, to make it match other special directories like _build?