Add email client to send emails via celery tasks

[stefanotroncaro]

• Added a CeleryTaskEmailClient, which schedules an email sending task instead of sending the email outright.
• Configured app container to use the CeleryTaskEmailClient as default client
• Configured celery worker container to use other email client implementations (that synchronously send emails)
• Added configurable email sending retry logic by specific methods on the EmailService, through env variables.

[DanTcheche]

It's weird for me that the email has the information about the backoff. We are tying email data with celery data. Same for max retries.
This should probably be a parameter of this function independent from email.

[stefanotroncaro]

I get what you mean.

The intention behind the context field is to represent metadata related to the email, which can be used by the different clients to customize behavior. This can range from the error message that needs to be generated upon failed delivery, to, in this case, the backoff value. Perhaps simply metadata would have been a better name for the field.

We could create an email metadata class by itself and pass the email and metadata objects as different arguments, but then the metadata would lose its association with the correct email object, which feels off to me.

Alternatively, we can set the backoff and growth base as env variables and have them apply to all emails. Perhaps we don't need to be able to customize those values individually for each particular email? The previous implementation suggested that such versatility was intended, as it attempted to configure independent env variables for each kind of email.

What do you think?