PURPOSE

Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.

RATIONALE

Add tests related to not standard usage of email field. Two main use cases
are tested here

  * formatted emails: `"Full Name" <email@domain.com>` stored into the 'email'
    field;
  * multi emails: `email1@domain.com, email2@domain.com` stored into a single
    'email' field;

Additional tests: tests with unicode / ascii / case / wrong formatting are also
added to check the support in normalize and format methods.

IMPLICATION

Email field is generally managed as "containing a valid email". This means
it is sometimes used as it in 'formataddr' as well as to perform searches or
identification checks. Example of issue: partner 'Raoul' has a formatted email
like "Raoul" <raoul@raoul.fr>. Using 'formataddr' in email_from leads to

  from: "Raoul" <"Raoul" <raoul@raoul.fr>>
  -> which is incorrect (but often dynamically corrected by email servers);

Email field holding multi-emails are not normalized, as current normalize
is done only if the field holds a single email. It means

  * no easy finding based on 'email_normalized', e.g. various tools like
    '_mail_find_partner_from_emails' or 'find_or_create' do not find partners
    based on this email;
  * no exclusion list management;
  * issue with formatting, like

  to: "Raoul" <raoul@raoul.fr,raoul.other@raoul.fr>
  -> which is incorrect (but often dynamically corrected by email servers);

USAGE: OUTGOING EMAILS

Those use cases currently generate faulty outgoing emails. This is valid for
recipients ('email_cc', 'email_to') as well as author ('email_from').

For formatted emails: `email_to` is formatted again based on name and email
which leads to sending emails to `"Full Name" <"Other"<email@domain.com>>`.

Note that multi emails without formatting may work as it leads to email_to
`"Full name" <email1@domain.com,email2@domain.com>`. Some outgoing email
servers correctly send multiple emails. It depends on their fault
tolerance.

USAGE: FIND BASED ON EMAIL (NORMALIZED)

When searching for partners (e.g. using '_mail_find_partner_from_emails' or
'find_or_create') normalized version of input is used.

In case of multi emails sanitize is 'False', as normalization expects a single
email in the field. Therefore no partner is found. In processes that do a
"search or create" (e.g. using a template on a record) this leads to creating
a new partner (or several partners in case of multi emails) each time.

USAGE: OTHER FLOWS

Other flows are build on top of '_mail_find_partner_from_emails' / 'create'
of outgoing emails and are impacted by formatted email / multi email usage.
Those include notably

  * mass_mailing: '_message_get_default_recipients' should be defensive to
    give correct values when creating mailing emails;
  * mass_mailing: faulty emails is based on normalize and multi-emails are
    considered as faulty and ignored;
  * after post hook: '_message_post_after_hook' tries to link messages without
    author (but email_from) with newly-created partners, when partners are
    created from chatter. It is therefore impacted by those corner cases;
  * marketing_automation: built on top of mass_mailing and suffers from the
    same issues;

USAGE: UNICODE

Unicode in emails should be supported. 'formataddr' and IrMailServer notably
received fixes to support unicode. Some check performed on email addresses
fail when unicode is involved, which leads to some emails not being sent
while they could.

SPECIFICATIONS

Add tests related to those corner cases. Also add tests for computation of
`email_formatted` field of Partner model. It currently generates wrong email
values for the same corner cases (multi emails, formatted emails).

Tests are also added for the computation of `email_normalized` field used
notably for blacklists. It is not computed currently when being in multi
email mode which prevents from any blacklist mechanism as well as make
email finding harder. `_mail_find_partner_from_emails` tool method is also
tested with multi email as it uses the same heuristic as normalized email
field.

Tests are also added for mass mailing, when having to mail documents that
have a partner with formatted emails / multi-emails, or that have an email
field with formatted emails / multi-emails.

Also restore a test removed at odoo/odoo@afcb7349083c669dbda18b9b1955eabbe14ea675 while it should have been
updated to state that email addresses containing non-ascii characters are
supported.

Add some tests for tools methods used in various email processing flows.
Unicode tests are also added.

In future commits we will try to make email usage a bit more defensive to
try to lessen issues with that kind of use cases.

Task-2612945 (Mail: Defensive email formatting)

X-original-commit: odoo/odoo@6e0b1a318447ffef3857c9fd5c975108a1c3944e
Part-of: odoo/odoo#134188