Use structured DSN instead of URI in system.mail mailer_dsn

Love the idea, think we will need a change record for it.

Load balancing could be supported by providing multiple DSN configs, although it might complicate things a bit.

$config['system.mail']['mailer_dsn'][] = [
  'scheme' => 'smtp',
  'host' => 'smtp.example.com',
  'port' => 25,
  'user' => 'user@some-domain.org'
  'password' => '^C>6P2EdL.b<?9jBXgOu8*A>'
];
$config['system.mail']['mailer_dsn'][] = [
  'scheme' => 'smtp',
  'host' => 'smtp.anotherexample.com',
  'port' => 465,
  'user' => 'anotheruser@some-domain.org'
  'password' => '^C>6P2EdL.b<?9jBXgOu8*A>'
];

or

$config['system.mail']['mailer_dsn']['default'] = [ 
  'scheme' => 'smtp',
  'host' => 'smtp.example.com',
  'port' => 25,
  'user' => 'user@some-domain.org'
  'password' => '^C>6P2EdL.b<?9jBXgOu8*A>'
];
$config['system.mail']['mailer_dsn']['second'] = [
  'scheme' => 'smtp',
  'host' => 'smtp.anotherexample.com',
  'port' => 465,
  'user' => 'anotheruser@some-domain.org'
  'password' => '^C>6P2EdL.b<?9jBXgOu8*A>'
];

> It is an advanced use case and for that kind of things we have contrib.
I agree. It's part of my plan for DSM, but it hasn't been implemented yet😃.

I think it's a very good idea, and it's similar to what we already do in DSM.

I see you have matched the names of each parameter to the DSN class, which does make sense. FYI In DSM we used 'pass' (to match the examples in https://symfony.com/doc/current/mailer.html) and 'query' (because they are query parameters).

Rebased so I could run the test-only feature

There was 1 failure:
1) Drupal\Tests\system\Functional\Update\MailDsnSettingsUpdateTest::testSystemPostUpdateMailerDsnSettings
'sendmail://default' does not match expected type "array".
/builds/issue/drupal-3399645/vendor/phpunit/phpunit/src/Framework/Constraint/Equality/IsEqual.php:94
/builds/issue/drupal-3399645/core/modules/system/tests/src/Functional/Update/MailDsnSettingsUpdateTest.php:41
/builds/issue/drupal-3399645/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
FAILURES!
Tests: 1, Assertions: 179, Failures: 1.

If we add to the existing CR think it should be noted with

$config['system.mail']['mailer_dsn'] = [
'scheme' => 'smtp',
'host' => 'smtp.example.com',
'port' => 25,
'user' => 'user@some-domain.org'
'password' => '^C>6P2EdL.b<?9jBXgOu8*A>'
];

is possible and the problem with load balancing.

rest looks fine.

I do wonder if we should just move to the structure in #9, allowing multiple DSNs but only supporting 'default' in core, similar to the way we allow multiple database definitions but in practice only the 'default' is used except for special cases. Wouldn't this then make life in contrib easier? Otherwise I think you will have to override this entirely and provide multiple configs elsewhere, and the system.mail one becomes redundant?

Sending this back to RTBC. I think this is a valid improvement that we should get in before 10.2.0 otherwise we risk having to provide some form of BC.

I was wondering if this did not mean we lost schema validation but it is the opposite, we are gaining a lot of validation here. I wonder if we should add the same regex we added in #3379102: Add validation constraint to `type: label` + `type: text`: disallow control characters, to disallow control characters?

I think that can be a follow-up.

Discussed with @catch. We would like to land this in 10.2.0 to avoid adding backward compatibility later, but because we already released beta1 there is a chance some users will now have the old structure in their config.

As we cannot delete post update hooks, we propose making the old post update hook a no-op and overwriting the config with the new structure in a new post update hook. This will cover users upgrading from beta1 or earlier to the next release; we don't expect anyone to have started using this feature yet so we can safely overwrite the config as long as we do it before 10.2.0.

The approach to updates from beta1 to 2 make sense.

I guess we could add something to the release notes about needing to reconfigure it.

Committed and pushed 0b7c2a60a5 to 11.x and 749e1f030f to 10.2.x. Thanks!

Tagging for change record updates, as the examples there need to be updated now.

Also tagging for release notes as we can add a line for beta-to-beta upgraders, just in case anyone started looking at this.

The updated change record looks good to me, thank you @znerol. Added a release note snippet as well.