Refactor mail to produce an intermediate "bag of strings" object in preparation…


Refactor mail to produce an intermediate "bag of strings" object in preparation for SMS

Depends on D19954. Ref T920. This is a step toward a world where "Mailers" are generic and may send messages over a broader array of channels (email, SMS, postal mail).

There are a few major parts here:

  • Instead of calling $mailer->setSubject(), $mailer->setFrom(), etc., build in intermediate $message object first, then pass that to the mailer.
    • This breaks every mailer! This change on its own does not fix them. I plan to fix them in a series of "update mailer X", "update mailer Y" followups.
    • This generally makes the API easier to change in the far future, and in the near future supports mailers accepting different types of $message objects with the same API.
  • Pull the "build an email" stuff out into a PhabricatorMailEmailEngine. MetaMTAMail is already a huge object without also doing this translation step. This is just a separation/simplification change, but also tries to fight against MetaMTAMail getting 5K lines of email/sms/whatsapp/postal-mail code.
  • Try to rewrite the "build an email" stuff to be a bit more straightforward while making it generate objects. Prior to this change, it had this weird flow:
foreach ($properties as $key => $prop) {
  switch ($key) {
    case 'xyz':
      // ...

This is just inherently somewhat hard to puzzle out, and it means that processing order depends on internal property order, which is quite surprising.

Test Plan: This breaks everything on its own; adapters must be updated to use the new API. See followups.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T920

Differential Revision: https://secure.phabricator.com/D19955