Barcode, default_code (Internal Reference), standard_price,
volume, weight fields are not saved when we create a new product.

This is due to the fact that these fields need the product_variant_ids
field to be set, in order to compute their values.

Due to migration in rev https://github.com/odoo-dev/odoo/commit/1aa5bc0fdfa402ac7cccbc3a7203ec5050f6339b

[ADD] Allow to pass a value in the context during import in order to allow the addition of new record in many2many field instead of replacing the current value with the imported value: in other words replace [(6, 0, [ids])] by [(4, 0, id1), (4, 0, id2), ...]

* Tokenization from ecommerce checkout
* Authorization/capture flow
* Advanced feature support for payment providers
* Server2server and auth_only tx for authorize.net
* Adapt Ogone s2s flow to new payment flow

Impacted modules:
* payment
* payment_ogone
* payment_authorize
* website_sale
* website_portal_sale
* webste_quote

This commit improves the tokenization process, allowing users
to set the acquirer to save payment data never, always or letting
the customer decide (only implemented in ecommerce for now).

Support for tokenization is improved for Ogone and Authorize.net

This commits also factorizes advanced payment features support
(authorization, tokenization, fees computation) in a generic method
overriden by every provider to specifiy which features are supported.
This process can be used in views to hide/show fields depending on
feature support or in constraint checks.

Instead of having to register a card then do a payment, a little
checkbox during the checkout process is usually simpler.

This commit add s2s communication to the Authorize.net payment
provider, allowing the user to:
- Create a payment token
- Charge a payment token
- Authorize/capture transactions

Since the creates overrides needs some information that do not end up
in the final record, let's avoid warning by removing all non-model
fields from the call to super.

This allows using a modern e-commerce flow where amounts are first
authorized at checkout then captured when the picking is in fact
shipped instead of immediately capturing the amount.

To access this flow, a new selection value is available on the payment
acquirer: "Authorize the amount and confirm the SO on acquirer
confirmation". If this value is selected, s2s/form transactions should
only require authorization to the acquirer; the user can then
capture/void the payment manually from the Odoo backend transaction
form view by simply using buttons.

An old hack simple overrode the standard python ValueError instead
of except_orm, which explains how it survived for so long.

Even if the model is called res partner category, it is now used like tags
and should be labelled as such.

You probably want to know what you won over the month.

This option implies 3 changes:
 * a default char field x_name on the new model
 * be able to infer the `model` of the ir.model in name_create
   from its `name`
 * avoid deleting the registry when unlinking *nothing* ; the default
   field_id or ir.model ([(0, 0, ...)]) implies an unlink ([(5,), (0, 0)])
   that delete the current registry

Courtesy of @rco-odoo

As these views will soon be accessible out of debug mode,
let's simplify them by hiding some fields in non-debug mode.

As this lib will be used in the backend, it is moved to assets common.

The API of `Registry` has been modified as follows:
 - `Registry(name)` returns the registry of the given database
 - `Registry.new(name)` forces the creation of a new `Registry` object
 - `Registry.delete(name)` discards the given registry
 - `Registry.delete_all()` discards all registries
 - `registry.setup_signaling()` initializes the signaling for `registry`
 - `registry.check_signaling()` returns an up-to-date `registry`
 - `registry.signal_registry_change()` notifies that `registry` has changed
 - `registry.signal_caches_change()` notifies potential cache invalidation

This merge holds several long awaited improvements for the mail gateway.
It includes

 * store email status of notifications emails sent to customers
 * display this information on Chatter
 * improve bounce email management: track bounced notifications emails, use
   message_bounce fields directly in mail and not in mass_mailing
 * send emails to assigned user on records
 * remove required alias on users while keeping it possible to define alias
   on users and use them
 * handle emails forwarded to aliases as new threads instead of replies
 * do not store needaction for forum and blog posts
 * automatically unsubscribe partners that bounce on channels
 * some light code cleaning

If a partner bounces more than 10 times on a channel, unsubscribe him from the
channel.

Forum and blog are public models that could have a lot of followers. After
notifying followers of a new comment, discard the needaction information.
For those models email is considered as sufficient. This way we avoid storing
a lot of unnecessary entries in the m2m table between message and partner.

It has been solved using the standard way of managing buttons in notification
emails. At least we hope it.

Having followers having an email address being an alias is rarely a good idea.

If the 'To' of an incoming email is an alias on another model we now consider
this emails as a forward to a new alias. A use case for this is an email on
a task that should be considered as an issue and forwarded to another alias.

When a user is assigned to a model on a user_id field an email is sent to him
containing a link to the document. This way the user is warned he is now
responsible of the task / issue / lead / ...

Using after commit event notifications emails are now send once the current
transaction is finished. This allows having issues with emails being sent
while the transaction failed sometimes after email sending, but still in the
same transaction.

A small hook is done to allow invitation emails to be sent directly as some
data related to mail.message is unlinked directly in the wizard.

This commit remove required alias on res.users model. It also removes the
inheritance of mail.alias.mixin. The field alias_id is kept and allow people
to use aliases on users if they want. However there is no default void alias
created for each user anymore.

Default from of mail.message does not use user alias anymore. Indeed this
creates issues with aliases not being correctly configured and can be
confusing compared to private channels. Using user aliases is therefore
now done manually instead of being a default behavior.

Handle bounces using bounce alias directly in mailgateway. Previously bounces
were used only in mass mailing to update campaign statistics. Now the
mailgateway tries to find data from standard delivery status emails. This
data is used to update state of emails sent to customers, to display it in
the Chatter. It is also used to increment the message_bounce counter on the
bounced partner and bounced record, if any and if the field exists.

Previous more generic code that detect bounces is kept. This code is more specific
to standard delivery failure notifications by parsing its content.

Currently it is impossible in Discuss to know whether an email has been sent
to a customer and whether it failed or bounced. A notified partner has an
entry in the needaction m2m table. In this commit we decorate this table to
add fields about the email notification: is an email sent, did it failed, did
it bounce.

This information is kept only for customers. Internal users does not use this
information. Moreover their notification is deleted once the message is read
in the Chatter. This avoids having a notification table that grows quickly.

Chatter now holds a new icon for email details. It allows to know on a thread
status of emails sent to customers.

This is an old compatibility code. It is time to remove it as it is not used
sinces ages.

Previously Return-Path were composed using bounce_alias-<mail_id>-<model>-
<thread_id> . However this may lead to return adresses not supported by
the incoming mail server. We now form the bounce alias using bounce_alis+
<mail_id>-<model>-<thread_id>. Using a + indicates that the right part of
the address is for information and used to manage the bounce. Only the
left part is used for the email routing, allowing the return email to
effectively land in the alias mailbox.

When a new answer comes in a thread the mailgateway finds if the recipients
are linked to existing aliases. This allows notably to check if the author
can effectively contact this alias. Previously only the To was checked.
However we cannot ensure the recipient is contained in To as it could be
in Delivered-To for example. We now check for all possible recipients.

The purpose of this commit is to clean a bit the code related to email
routing in the mailgateway: message_route and message_route_verify.

message_route is now clearly separeted into two categories. First one
handles emails considered as answers to existing threads. Second one
handles emails that have to create new threads, either through alias or
default behavior of the mailgateway.

message_route_verify has been a bit facotrized to simplify the various
overrides that appeared lately in the codebase.

This commit only contains code cleaning. No functional change should occur
due to this commit.

Before creating a account analytic line related to a sale order, check that the sale order is in 'sale' state, i.e. not a quotation, not in done or canceled state.

The issue is that when validating an expense (for example, but it's the same for a timesheet), the analytic account line is created even if related to a canceled sale order which is obviously wrong. This was leading to confusions about what's displayed, what is existing and not displayed and whatever.

This was the behavior before this commit 48ea59d4