Bug
===
When we copy a GMail outgoing / incoming mail server, an error
occurs because we try to refetch the access token, based on the same
authorization code (which can be used only once).

To fix this issue, we do not copy the authorization code (and other
related fields).

Task-2751996

When the system broadcasts an email response to document followers,
if the config parameters `mail.force.smtp.from` or
`mail.dynamic.smtp.from` are defined, it will rewrite the `From`
address to avoid spoofing the sender's domain.
**NOTE**: As of 15.0, this is based on the `from_filter` setting on the
corresponding ir.mail_server, rather than the abovementioned config
parameters, but the rest of the discussion stands.

For example, if the `mail.catchall.domain` is set to `example.com` and
an email response comes from:

   "John D" <john@doe.com>

it will rewrite it to:

   "John D (john@doe.com)" <notifications@example.com>

This will make sure the system never sends outgoing email for an external
domain, as it has no authority for doing so, and that could
break mail filtering/authentication rules (SPF, DMARC, etc.)

During this "encapsulation rewrite step", both the original Sender name
and their email are preserved, and put into the quoted "name" field of
the rewritten address. It seems sensible to preserve as much information
as possible about the original sender.

Unfortunately, the inclusion of the Sender email in the final name makes
it appear to some inbox providers as if the message is trying to
deceptively impersonate another person (as many phishing schemes would).
As of November 2021 GMail at least does this, and will hide the name in
the UI when it happens. It will keep only the rewritten email, which is not
very useful in the case of a notification (even though it's more
technically correct, of course).

This patch removes the original email from the rewritten notification,
keeping only the name, considering that the email is not the most
important part, and it's better to have one of the two than none.

So after the patch, the rewritten address is now:

   "John D" <notifications@example.com>

When there is no name in the original address, we keep only the local
part of the email, to avoid the same display issue. The recipient will
have to identify the sender based on the context / past messages.

closes odoo#81807

X-original-commit: 3c65ec5
Signed-off-by: Olivier Dony <odo@odoo.com>

Purpose
=======
As it has been done for Gmail, we want to add the OAuth authentication
for the incoming / outgoing mail server.

Specifications
==============
The user has to create a project on Outlook and fill the credentials
in Odoo. Once it's done, he can create an incoming / outgoing mail
server.

For the authentication flow is a bit different from Gmail. For Outlook
the user is redirected to Outlook where he'll accept the permission.
Once it's done, he's redirected again to the mail server form view and
the tokens are automatically added on the mail server.

Technical
=========
There are 3 tokens used for the OAuth authentication.
1. The authentication code. This one is only used to get the refresh
   token and the first access token. It's the code returned by the user
   browser during the authentication flow.
2. The refresh token. This one will never change once the user is
   authenticated. This token is used to get new access token once they
   are expired.
3. The access token. Those tokens have an expiration date (1 hour) and
   are used in the XOAUTH2 protocol to authenticate the IMAP / SMTP
   connection.

During the authentication process, we can also give a state that will
be returned by the user browser. This state contains
1. The model and the ID of the mail server (as the same mixin manage
   both incoming and outgoing mail server)
2. A CSRF token which sign those values and is verified once the browser
   redirect the user to the Odoo database. This is useful so a malicious
   user can not send a link to an admin to disconnect the mail server.

Task-2751996