This merge replaces followers subscription code in order to be optimized
and perform less queries. This improvement is done in several steps :

 * mail followers model has new low-level and optimized methods to compute
   followers to create or update. It uses SQL queries to fetch data in a
   single request;
 * mail thread message_subscribe method is rewritten to use this new method.
   Its API is also simplified and message_subscribe_user is removed to
   simplify the whole subscription API;
 * auto subscription is also rewritten. Fetching subtype data about parent /
   child like project / task is done in a single query that prepares data.
   It then uses new method to create followers;

Various addons are updated because of message_subscribe or auto subscription
change. Functionally behavior should stay the same as purpose is to be
equivalent in term of functional coverage.

Performance counters show this optimized code works well when dealing with
large set of followers to subscribe or update. Most tests perform better
of a few queries. Most complex ones involving (auto) subscription of several
followers perform way better. About 30% of query are saved in the three top
tests, aka between 80 and 90 queries with auto subscription of 10 followers.
On overall community runbot we have a gain of about 11K queries. As Odoo
data has few followers impact on runbot is probably less interesting than
impact on real-life use case.

Thanks to @rco-odoo for reviewing, and cheers !

All code using it has been gradually replaced. It can be safely removed.

Expense report has custom code to add people as followers. This code has
several issues, notably in some cases it could try to add several times
same people, leading to crash and issues.

As auto subscription has been cleaned let us clean the code in hr expense.
Using _message_auto_subscribe_followers it is now simpler to automatically
add follower to expense reports. It is not necessary to add hackish custom
code in create and write.

One change is done in this commit. Some people are set as follower after
record creation and not before. However this was necessary when tracking
messages were not correctly triggered or auto subscription done after
tracking. As process is now 1/ create 2/ auto subscribe 3/ tracking, messages
linked to tracking will be correctly push to recipients automatically added
as followers.

This commit refactors mail.thread message_auto_subscribe method. Purpose
of this method is to automatically subscribe people to documents in several
scenarios

 * followers from an umbrella record to sub-records, like followers of project
   added to tasks;
 * responsible of documents, in addition to sending notifications to newly
   added responsibles;
 * some specific use case depending on some applications like managers
   for expense reports;

New auto subscription now uses the recently introduced method optimized to
compute new or to-update followers. It is also rewritten so that overriding
it is easier. Indeed simply overriding _message_auto_subscribe_followers is
now sufficient to add new followers to a record, depending on some updated
values. It is also now possible to specify a template to use for some
specific notification, if requested.

Fetching auto-subscription data in subtype is also optimized. It is now done
in a single SQL query. All data related to parent (like project) and child
(like task) as well as default and internal-only data is prepared in a single
query and given back to auto subscription process. This allows to gain
queries in auto subscription based on subtype like project / task use case.

This commit has a great impact on performance counters. Complex use cases
involving tracking and responsible notifications gain about 30 queries which
is about 15% of their total query count.

This commit refactors mail.thread message_subscribe method. It is done for two
purposes. First one is to optimize performance by using the new followers
computation methods introduced recently. Second purpose is to clean the API
of message_subscribe to make it simpler to use.

This commit splits message_subscribe in two main parts :

 * _message_subscribe is a private method calling the follower new
   subscription methods and updating the record set;
 * message_subscribe is a public wrapper on _message_subscribe that adds
   access rights checks;

Simplification comes by removing message_subscribe_users that was a
shortcut to message_subscribe. Having a method to subscribe partners and
channels is sufficient as we would like to avoid bloating the public API
of mail.thread. A force parameter is also removed from message_subscribe
as this implementation detail can be induced in the computation.

Various addons using the removed methods are updated in order to use the new
subscription API. They have the same functional behavior.

This commit has a great impact when subscribing several followers. In a more
general way all code using message_post is also optimized as posting a message
generally implies subscribing followers. It also improves activity use as
posting a message and subscribing new followers are common process in
activities.

Override of create in mail.thread now uses the recently introduced
_add_default_followers to add the record's creator in the followers.

It allows to save one query when creating new records. It means for simple
models we approach the bottom limit in term of generated queries which is
quite a good news.

This commit adds new methods to add or update followers to documents. Purpose
is to have new optimized methods that perform less queries. It is based on
experience and use cases of various addons in Odoo using it.

Technically two main methods are given on mail.followers model

 * _add_followers: this method generates values required to create new
   followers or update existing one. It takes several parameter controlling
   how to deal with existing followers. This is used notably when auto
   subscription should not erase existing subscriptions;
 * _insert_followers: this method creates or updates followers for a given
   set of documents. It uses result from _add_followers;

Performance gain come from the use of a SQL query to fetch followers data
as well as less use of record sets. Code can be more low-level in some
places. Purpose is to avoid browse and prefetch and just fetch data once
and use it in various computation.

New implementation is equivalent to the old one. It offers more flexibility
as caller can either receive values for followers or directly have records
created and updated. Various parameter allow to tune computation depending
on each specific call to the new follower methods.

Future commits will gradually replace the use of old _add_follower_command
by the new methods. Purpose is to replace them one by one in order to see
the gain in term of performance one replacement at a time.

Move zoom next the original picture
Disable it if same img and max size with ratio < 1.5
Allow to enable zoom automatically
...

Task-33499

Co-authored-by: Jérémy Kersten <jke@odoo.com>

In the normal course of saving-action, readonly fields are stripped
out when sending data to the server. The SSF would reuse the same code
when "saving" O2M lines to the parent record however that is not
correct and would lead to misbehaving views as readonly (non-stored)
fields used as "transients" (storing data within the extent of a
record's edition session) would not behave properly.

Fix by overriding the O2M Form's save so that readonly fields are
kept and stored in the parent record.

Closes #23620

This rev. extracts two rendering parameters for the groups
corresponding to the default col value to apply (for inner and for
outer groups). This allows to easily override those default values
in extentions of the FormRenderer (for instance, in the renderer
of the new Dashboard view).

This rev. refactors the way the view's arch is parsed in BasicView,
so that it can be extended specifications of the BasicView to
handle other tagnames that 'field' (which is basically the only
one handled in BasicView).

This rev. extracts the part of the rendering that renders outer
groups (i.e. groups that contain groups) in its own function. This
allows extentions of the FormRenderer to use it (for instance, the
renderer of the new Dashboard view).

This rev. introduces an option to doAction (keepSearchView). If set
to true, the searchView of the current action will be kept and used
by the new action (this only works if there is already an action
with a searchView, and if the new action is stacked over that one).

This is necessary for the new dashboard view.

A better solution would have been to export the state of the
existing searchView, and import it to the new one, but the current
implementation of the searchView doesn't allow to do that easily.
This will be done as soon as the searchView will be rewrote.

This rev. allows to add or remove filters to the SearchView from
the outside, and to make it display this new domain. This can be
used by views that trigger domain changes (e.g. this is the case
of the new DashboardView).

The graph view uses the nv(d3) lib to render the graph. This lib
requires that the rendering is done directly into the DOM (so that
it can correctly compute positions). However, the views are always
rendered in fragments, and appended to the DOM once ready (to
prevent them from flickering).

Before this rev., the graph view circumvented this by performing
the rendering in a setTimeout(0), letting the framework append the
widget to the DOM first.

This rev. removes this hack and uses the on_attach_callback hook
instead, which is called when the widget is attached to the DOM.
This ensures that the rendering is always done in the DOM, and we
keep the rendering part synchronous.

This rev. adds a new formatter for numerical values to fieldsUtils.

Complement of 802339c1

When creating a timesheet, several fields need to be recomputed:
- `currency_id`
- `group_id`
- `department_id`
- `is_timesheet`
- `validated`

When `validated` is computed before the other fields, the recomputation
will lead to an `AccessError` because of the rule
`hr_timesheet.timesheet_line_rule_user`.

Since the test `test_timesheet_validation_user` expects an
`AccessError`, the test succeeds. However, from time to time,
`validated` is computed last => the `AccessError` is not raised.

Actually, a `ValidationError` should be raised in this case (from the
`create` override in `timesheet_grid`).

Before this commit:
Clicking on 'unstar all' button removes all messages from starred channel
but it only decreases the counter as many as there are displayed messages
on screen.

For example, if there are 40 messages starred, only 30 messages
are on screen (default limit) but unstar all will decrease counter
only for those messages instead of 40.

After this commit:
clicking on 'unstar all' button will correctly take in account all
fetched messages and not only displayed messages.
So now, after clicking on 'unstar all' button will update the starred
counter to 0.

task-ID: 33958

Previously, the ISR reference was computed from the iban number but it seems some banks (for example UBS) use arbitrary ISR references that needs to be manually set.

Was task: 40975
Was PR #22931

After this rev., in Discuss, messages are automatically loaded when
the user scrolls to the top of the channel.

Task 33958

Co-authored-by: Aaron Bohy <aab@odoo.com>

The caller of `read_group` can now provide the aggregating function to use for
a given field:

    # set aggregating operator for fields 'foo' and 'bar'
    model.read_group(domain, ['foo:sum', 'bar:avg'], ...)

One can also aggregate the same field several times, by giving a specific
output name for each:

    # aggregate 'foo' with both 'min' and 'max'
    model.read_group(domain, ['foomin:min(foo)', 'foomax:max(foo)'], ...)

for actions in target='new'. Before this rev., it was only called
on the dialog, but not on the controller rendered inside it.

Field enaming introduced at https://github.com/odoo/odoo/commit/bfe362c87a2c058c9257166dca096d80c79d3dc3 left some references to old field name. #oops #cestpasmoicestlui

When using cash basis taxes, the user has now the possibility to select a cash basis account containing the base amount during the generation of accounting entries.
This commit has been backported in v9 (in form of a module) in revision 1631889e

  - task: https://www.odoo.com/web#id=40284&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
  - Was PR #22599

This is needed to allow having a single bank statement validating 2 payments in case of our internal OGONE processing. An incoming commit in account_batch_deposit will explain more in-depth the use case covered

Payments created without partner_type (field not required) were previously not shown anywhere.

Deleting comment / note / activity subtypes make the whole system quite
impossible to use. Indeed the whole communication mechanism is based on
those subtypes that are hardcoded.

There are some use of env.ref() about subtypes to try to avoid having those
removed. As there is some work to make some xml ids impossible to delete we
can already update some code to use xmlid_to_res_id instead of env.ref(). This
leads to some gain in query count as there is no exists() that is performed.

Globally this merge allows to save a few query on each message post and about
7K on community runbot.

As explained in previous commit we can use xmlid_to_res_id instead of ref()
which leads to some query gain. This commit update some other less important
places: when setting activities as done and in the composer. This lead to
a gain in tests involving activities and composer, including tracking
triggering a template. On community runbot this leads to a gain of about 1K
queries.

As explained in previous commit we can use xmlid_to_res_id instead of ref()
which leads to some query gain. We gain 1 query on most post due notably to
notify and logging is still improved. This leads to a gain of about 4K queries
on community runbot.

Deleting comment / note / activity subtypes make the whole system quite
impossible to use. Indeed the whole communication mechanism is based on
those subtypes that are hardcoded.

There are some use of env.ref() about subtypes to try to avoid having those
removed. As there is some work to make some xml ids impossible to delete we
can already update some code to use xmlid_to_res_id instead of env.ref(). This
leads to some gain in query count as there is no exists() that is performed.

Gain: 1 query on most tests implying post, because message_format is called
by bus notification. About 1.5K queries on community runbot

Still this "sometimes one query more" in activity-related tests. Let us avoid
false red occurrences of runbot by adding one query on sometimes-failing tests.
Purpose of performance test is to have an idea of query count. Adding one query
is not harmful.

    - Removed 'OK' button to save title. Now, title will be saved on focusout or enter key pressed.
    - If more than one statements to be reconciled, then title should not be editable.
    - If no title for statement display text 'No Title'.
    - Improve UI for title to better understand clickable area and fix issue if title is too long.

Was task 34890. Was PR #19971

It is not a technical feature

Size attributes (e.g. `max-width`) are sometimes set in css (i.e. with classes,
see `oe_avatar`).

They must however be overriden if they are specified on the widget.

Example:
  <field name="image" widget="image" class="oe_avatar" options="{'size': [180, 180]}"/>

The `max-width: 90px` set on oe_avatar must be overriden in this case.

Note that the attribute `img_width` and `img_height` have been depreciated as
`width` and `height` are fulfilling the exact same purpose.

Accounting entries made for invoices and stock valuation on the interim accounts (stock input/output accounts) are now reconciled together for both sales and purchases. This will definitively help to have those accounts zero-outed when all operations are processed.

The reconciliation is made as long as the stock valuation is set in real-time, whatever the costing method.

Note that change change also allow a particular use case to be solved: when a purchase is made in a foreign currency whose rate change between the incoming shipment reception and the bill validation (there will be an automated exchange rate entry created).

Was task 32331. Was PR #22483