DeltaChat bot as additional command interface

[missytake]

Context: #36

basically #23, but rebased on master and with some more progress.

Overview over the changes:

• add mailadm setup-bot command to initialize the admin group
• add add-token, add-user, and list-tokens commands to the bot interface
• add a check whether a message comes from the admin group
• add a thread to the gunicorn process which takes care of pruning every 10 minutes
• move add-token, add-user, list-tokens, and prune logic from cmdline.py to commands.py
• change list-tokens output format to be more human-readable (including tests)

To do:

• remove install_mailadm.sh & uninstall_mailadm.sh on master and rebase afterwards: remove old install & uninstall scripts #47
• remove "add support for passing a custom MAILADM_HOME to pytest" - not sure why I even did that
• add bot.run() thread to app.py
• add clear_pw to UserInfo (tests are complaining)
• move prune logic from app.py/cmdline.py to commands.py
• get python bindings: move account initialization to separate function deltachat-core-rust#3519 merged and released, depend on this core version
• actually receive commands with the bot
• make deltachat database persistent in the docker setup
• re-configure account if new credentials are passed
• add meaningful responses to /add-user and /add-token
• bot-thread picks up credentials without having to restart after mailadm setup-bot
• install on test server and go through the flow. Does it work? What doesn't?
• are more tests needed?

[missytake]

This is ready for review! Finally, it took almost a year to get this ready. We can build more features on top of this, but it should be a good foundation, and all the conceptual problems are solved now, I would say.

I think currently the /add-token name expiry maxuse (prefix) command structure is pretty ugly, it's still very close to a shell. it works, but one day it would be cool to have a webxdc for this or so 🤷.

I added @hpk42 to the Admin Group of x.testrun.org for now; if anyone else wants to be a part of this group to try it out, write me.

If you want to try out the mailadm setup-bot flow, you can login to b1.delta.chat and run: sudo docker exec mailadm-leslie mailadm setup-bot (note that if you want to change the bot's email address, you need to delete /home/leslie/mailadm/docker-data/admbot.d* for now, at least until deltachat/deltachat-core-rust#3530 is merged and released.)

[hpk42]

Suggested change

	You don't have to login with SSH every time you want to create tokens. You can
	also use the bot interface to talk to the bot in a verified Delta group. The
	bot needs an e-mail account to operate - it doesn't have to be on your mailcow
	server, it can be any e-mail account which also works with Delta Chat.
	You don't have to login with SSH or user docker commands every time you want to create tokens. You can rather setup a dedicated bot e-mail address and bootstrap a verified "admin group chat", in order to add/remove/list tokens for e-mail account creation. The bot's e-mail address can be any e-mail address and does not need to reside on the e-mail domain whose accounts it is managing.

[missytake]

Hm, not sure about that wording, but I rephrased it a bit along those lines. As it always is with writing, too many cooks...

[hpk42]

not robust enough i think: if for some reason a second person tries to join the admin group, then the event-thread will error and probably die, and become dysfunctional. If "chat.num_contacts() > 2" then a message should be send to the admin chat that there was a failed attempt at joining another address (and telling about the precise e-mail address which tried to join).

[missytake]

Hm, this hook is only used during setup-bot so we can wait until the user actually joined the group. So we actually want to check that exactly one person joined so far, because that means the script worked. But we want more users to join later, so it's not really something we would warn about.

It doesn't raise an exception anymore though.

[hpk42]

Suggested change

	chat = ac.create_group_chat("Admin group on {}".format(mail_domain), contacts=[], verified=True)
	chat = ac.create_group_chat("AAdmins {}".format(mail_domain), contacts=[], verified=True)

"Account Admins" :)

[missytake]

hmmm, not a fan^^ I mean, users can rename it as they want, but I called it an admin group to make obvious what it's for...

[hpk42]

this looks good to me, only a few remarks.
I'd prefer if there were also some unit tests for some of the functions in commands.py and bot.py but that's not a blocker.

[missytake]

If you are fine with my latest additions, just merge it :)

[hpk42]

why is this neccessary? Because "member added can now happen before verification is complete"? That sounds wrong, though. A member can only be added to a verified group if it is verified. I'd consider this a bug and this is a dangerous work-around which can block the "event execution" overall for the bot if the contact ends up not getting verified (because of lost messages etc.). If anything, then "for i in range(500): if contact.is_verified(): break else: time.sleep(...)" to limit the hanging.

[missytake]

Ah, the reason is that sometimes the welcome message arrives at the user before the "verification complete" message arrives - this makes the welcome message unreadable to the user, as it is sent by an unverified contact to a verified group. This was ugly, and this small loop should ensure that the welcome message is at least sent after the last verification roundtrip message.

I will take it out for now, as it shouldn't be a blocker for this PR. Maybe delaying the welcome message 5 seconds would help.