Create new mailer service based on symfony

Problem/Motivation

Part of stage 2 of 🌱 [META] Adopt the symfony mailer component Needs review . Create a new API with direct access to all the power of Symfony Mailer. Enhances the symfony code with integration into Drupal mechanisms, including theme/template/render, multi-language, CSS libraries, configuration, plug-ins, hooks, and logging.

Proposed resolution

1) New service 'mailer'
Thin wrapper on top of Symfony\Component\Mailer\Mailer

• Class Mailer implements MailerInterface
• Function send(EmailInterface $email) - similar to base Mailer class
• Convenience factory function create(string $id, array $params); that returns EmailInterface
• Function isEnabled(string $id) during the transition phase, allows modules to determine if they can use the new mail system. This check a global config setting, and allows hooks/events to alter the result per ID.

Responsible for the email building pipeline

• Build phase: allow modules to process the unrendered email (no rendering, translating, token replacement etc)
• Rendering: switch render context (to avoid leaking into current request), language, theme, user account (for access control and correct rendering of entities), render twig, replace tokens
• Post-render phase: allow modules to process the rendered email
• Send email
• Post-send phase: allow modules to react to the sent email

2) Callbacks: events and processors

Modules have two options for how to process mails.

• Handle an event (there is one event for each phase)
• Write an email processor class implementing EmailProcessorInterface, which has a function for each phase

All the events and functions have a single argument/member of type EmailInterface.

3) New class Email implements EmailInterface
This would enhance the symfony base class with some new fields:

• id ("module.key") used by events/processors, templates etc
• params array for use by hooks, templates
• langcode
• transport (allows to use a different transport for different types of mail)
• library/theme (used to attach CSS)

We need to make some changes to the base class, for example:

• The base function subject(string $subject) would force translation too soon, before the right language has been selected. We might prefer to rename setter method to match Drupal standard, e.g. setTo() rather than to().

Questions:

1) Should the new class Email extend the base symfony one, or decorate it (meaning have a class variable $inner containing the base class)?

• Advantage extend: we can pass our class everywhere where the base class is expected.
• Advantage decorate: we can make a clean start, renaming/removing functions or changing their parameters.

Remaining tasks

User interface changes

None

API changes

See proposed resolution

Data model changes

None

Release notes snippet