improve user onboard/offboarding procedures

while working on the nextcloud project, we realized it wasn't exactly trivial to setup the LDAP bridge because of our specific requirements (no direct connexion, offline support). so we just didn't implement it yet (legacy/trac#32332 (moved)). i added a note about this in the retire a user procedure, but then i realized there are probably many other such services that do not connect with LDAP.

On the top of my head, there's at least Trac and mailing lists, for example, which are managed completely separarely. Audit the service list and see which services are manager manually and which aren't. Those services have been identified as particularly out of sync:

• blog.torproject.org, see also https://gitlab.torproject.org/tpo/web/blog-trac/-/issues/33109
• email, see also #32558
• IRC, the @tor-tpomember group
• Nagios contacts (almost cleaned up, but will still need checking for sysadmins arriving/departing)
• Nextcloud (#32332 (moved))
• rt.torproject.org, see #34036 for an example audit
• gitolite, see #40023 (closed)

That list is not exhaustive.

Then make sure there's an automated way to add/remove users to services, either by hooking up the service with LDAP, or by creating a wrapper script that will manage those accesses.

So the following needs to be done here:

• document, in new-person and retire-a-user the service page, the various services to add/remove people to
• automate the above with a script or LDAP

Note that the two pages have different scope: new-person is about TSA while retire-a-user is broader. This should also be converged, probably in the broader sense.

Also note that a particularly tricky situation is when we want to do a partial removal. For example, maybe the person needs to be removed from tor-internal, but keep access to some servers. Or removed from server, but keep an email alias.

The latter case is especially sensitive: some people feel keeping their email alias around forever is an inalienable right and that we should keep forwarding their email even after they are fully retired from Tor. This policy needs to be clarified, see #32558 for that particularly tricky problem.