Plugin integration in email sending

[rixx]

Related to #1594, but going potentially deeper: It would be nice to have plugins handle emails entirely / optionally suppress the sending of emails. A use case for this would be an event that handles all speaker communications through a ticket system (like Jira, Zammad, RT, …).

Some thoughts on implementation and problems:

Super low level: email backend

Plugins can already implement email backends, which is what is getting called by mail_send_task. However, email backends get basically zero information: Just the message to be sent, nothing else. So no information of the message type, or even the event – and any message from password reset email to talk acceptance runs through there. We could scope the email backend to an event with a bit of effort, but that would still leave the problem of no context.

Mid level: queuedmail_pre_sent hook

Following #1594, we could implement a queuedmail_pre_sent hook, and give it a way to abort the actual sending of the message (probably by raising an exception), while still continuing to run the rest of the send() method (like setting the sent timestamp and saving the object). I'd still want to limit this hook to only handling QueuedMail objects with an id, thus allowing us to ignore any emails that are not visible to organisers (like password resets, speakers inviting other speakers, and crucially reminders to people with draft proposals, who never should be visible to organisers).

QueuedMail.send() does lack a bit of context (like the proposal an email is sent for, for example, or more generally the message context), and storing that context would be very annoying, as it basically requires generic foreign keys to a degree, but I do think it would be good enough to just … add the proposal(s) in question to a QueuedMail and have that be good enough. We already store the user account and the template (if any), of course.

High level: message sending plugins

An even better abstraction, imo, would be to allow plugins to register message sending capabilities, and turning the standard email sending into one such plugin (active by default). Organisers could then even activate multiple sending plugins, configure a priority, and if messages are allowed to be sent via multiple channels. Since QueuedMail objects can already be displayed by ID to the user, this would make it possible to e.g. send an SMS (I know, I know) just saying "new message from the $event organisers at $url", while also sending an email etc.

We'd definitely need to add the same level of context mentioned in the mid-level solution, and additionally flags for quiet / non-organiser-visible sending (which would be fine in some backends, like SMS, but not in others, like Jira). We'd have to hammer out an API that is somewhat future-proof, but I imagine that would largely be a mix of the to_mail() and the send() signatures.

I feel like this is the most flexible solution without adding too much of a maintenance burden – and while also making it somewhat likely that people will implement additional sender plugins for services like ticket systems, messengers etc.