Update email action to allow for custom SMTP and "from" address from defaults or override

[gabestein]

Motivation

So admins can send emails from their own email providers and email addresses/names in all email actions

We've gotten this request from a number of communities who have struggled in the past with emails going to spam and want to use their own providers as a result, particularly when it comes to inviting reviewers, which is already a challenge and a place where deliverability is particularly important.

Requirements

• Adds new fields for preferred "from" email address, "from" address name, and SMTP settings (server, protocol, port, username, password) to email action config setup
• If default values are configured in the new action defaults page (Action field defaults page #1039), render a checkbox to use the default values.
  • When checked during email action configuration, this disables the new fields above and shows default values in their place
  • If any default values are marked as secret, they are not shown; instead, they are displayed as ***

Acceptance Criteria

• SMTP username and password are encrypted
• Email actions for the community use the SMTP server, from address, and from name if provided

Extra work

• Way to test the SMTP settings in the settings page prior to saving them
• Update the email action to show the from address and name, if provided, and allow them to be overwritten in action settings

[gabestein]

A question I have here is should this be the start of a bit of a settings framework for actions, e.g., the settings are "registered" by the email action rather than built into core.

[gabestein]

• Add from and SMTP settings to action
• Cascading action settings page
• Shows same form you see when run the action. Fill in defaults.
• Hide inherited default values for now (or call some "secret")

[tefkah]

yeah interesting, we could either approach these as literal cascading settings, where we allow admins "global" settings for each action type (basically prefill the config form, but all options optional).
or we could have some priviliged set of settings (SMTP settings, authentication tokens/secrets) that you could fill into certain places (kind of like how n8n works)

the first option would probably be the easiest, and i do like the idea of a cascading settings framework. with the first option though, it gets kind of awkward if we want the admin to be able to choose between multiple "settings" on a per action basis. eg for secrets for the http action, you would not want to just set ONE authorization setting and use that everywhere, you would want to be able to eg choose the Overleaf token when you are writing an overleaf action. The HTTP "Authorization" option should then somehow know it is able to choose from these privileged secrets.

so i think if we are going to do cascading settings, we should allow users to create multiple settings per action, name them, and set one of them (or none) as the default, and then when running or configuring the action to inherit from a certain predefined configuration (or the default if they do nothing)

[kalilsn]

SMTP username and password are encrypted end-to-end

As usual, I wish we didn't have to store these secrets, so I want to be cautious about how we do! And I don't think we can actually do "e2e" encryption such that only the user can decrypt the data (client-side), since we have to send scheduled emails where there won't be a client session. But I think we should encrypt/decrypt our secrets using an AWS KMS key. And I think we should use separate keys for each community and/or user (this seems like a community level secret, but I'm guessing we will have user-level secrets eventually too), to minimize the damage if a key leaks.