Execution environment: Safely run code inside an environment with partially substituted system state / config

This is a subset of #3530860: Create a new mailer service to wrap symfony mailer.

Interesting. You have made it very generic and extensible. The downside is complexity: 3-4 times the lines of code compared with the straightforward approach in Drupal\symfony_mailer\Mailer and 9 extra files (plus it needs tests). The call stack becomes a harder to follow with many nested anonymous functions (whereas in fact only the render switch requires that - the others all operate inline).

My feeling is that we don't want such complexity unless we can conceive of a clear use case for it immediately inside Core. I do feel attracted to the idea of having an environment manager separate from the Mailer, and I would simplify it to a fixed set of things that it can alter, i.e. the 4 we already know. If anyone in Contrib really wants to add a 5th param then they can extend the class, and we could write our class to make that easy. Then we only need 2 files, probably less than half the code, and the interface simplifies to something like this (the manager will swap a NULL for the appropriate default)

$this->environmentManager->executeInEnvironment($function, $langcode = NULL, $theme = NULL, $user = NULL)

OR perhaps we could keep $environmentParams if you prefer, with string keys ['langcode' => 'XXX'] and if they are missing it uses the default??

When switching language, I believe we also need to do

$string_translation->setDefaultLangcode($language->getId());
$string_translation->reset();

TODO: Allow third parties to alter the environment params. E.g. invoke hook or fire an event

FWIW I feel we don't want a separate event. We can use the same event as for altering any other parameter on the email. An extra event would be nuisance for code such as DSM+ Mailer Policy that supports altering any of the parameters generically.

OK great. I'm not the right person to review the complexity of the implementation, so let's try and get another reviewer for that.

This does seem to meet the needs of the mailer project. I have put in an example in the IS that shows it fits in the context of #3530860: Create a new mailer service to wrap symfony mailer. Of course this is based on just one possible idea of solving that issue and the details would change, but the principle seems good anyway. Equally it would fit in MailManager (not that I propose changing that now!) or DSM+.

I have discussed this problem space during Drupal Dev Days with @znerol

I have tried to send mails in different languages in a single request (or later in symfony messenger).

I found various issues during this process.

LanguageRequestSubscriber::onContainerInitializeSubrequestFinished handles config overrides, but a few other services in Drupal core need a manual reset because they are not language aware and have already been initialized.

The issue are in TypedDataManager, EntityFieldManager, EntityMemoryCache and options_allowed_values().

I have a class called MailLanguageManager which handles the reset in combination with a custom language negotiation plugin.

// Clear prototype cache in typed data manager.
// @see https://www.drupal.org/i/2276749
// @see https://www.drupal.org/i/3221375
$resetPrototypes = \Closure::bind(
  function (): void {
    $this->prototypes = [];
  },
  $this->typedDataManager,
  $this->typedDataManager
);

// Rest options_allowed_values, because its not language aware.
drupal_static_reset('options_allowed_values');

// Flush cache in EFM
// \Drupal\Core\Entity\EntityFieldManager::getBaseFieldDefinitions has a static cache (not language aware)
$this->entityFieldManager->useCaches(FALSE);
$this->entityFieldManager->useCaches(TRUE);

$this->entityMemoryCache->deleteAll();

The complete code (MailLanguageManager and LanguageNegotiationMail) is this github gist: https://gist.github.com/webflo/af03a8d49cd546ead4903669fe9dadf8