Delegate to models `ir.model` and `ir.model.fields`, so that this functionality
can be extended easily.

Before this commit, it was possible to edit something in an editable
list view, then press the DOWN key, then enter some other values.  With
the DOWN key, the focus is supposed to move to the line below, so we
save the current line, in the current state.  This means that the edit
coming after are simply lost (well, just not saved nor displayed).

What this commit does is simply disable all control elements in that
situation.  This prevents uncomfortable situations from occurring.

Before this commit, when a kanban view was grouped by a selection field, the
column were named with the raw value of the selection instead of the display
string.

Furthermore, fix the fact that when the column title was 0 or False,
'undefined' was displayed instead.

- Fix the toolbar behaviour since there is no more dataset in the widget.
- Improve the communication beetwen the controller and the toolbar.
- Move the code linked to the document upload in the right file.
- Adapt the tests to mock the search_read done by ´document´ addon
- Adapt the mock server to be able to give a custom toolbar action

This commit proposes to allow to automatically generate timesheet lines
when an employee is on leaves. Project and task used for timesheeting
is globally configured on the company. Holidays type choose whether to
generate timesheets or not and take the company default configuration.

When an HR officer validates a leave request, analytic lines will be
generated for each day off. The unit amount will be based on the working
calendar of the employee taking the leave. Generated timesheet lines are
attached to the project and task configured on the holidays type.

Configuring timesheet lines generation at holiday type level allows to
tune the use of leave requests. You may have for example "home working"
holiday type that should not generate timesheets while "legal leaves"
should.

[IMP] hr_org_chart: help sentence
[IMP] sale: search on customer in main search

Before this commit, if the user created a line (thanks to the create
button) then deleted it, the rows were in a broken state which made the
list edit the wrong line on line click (it opened the next one). This
was due to row indexes which are kept as data on rows: they were not
updated on row deletion. This commit simplifies the code by getting rid
of this indexes data and instead compute those when necessary.

Since the account is a mandatory field, we raise an clear error is no
account is defined.

This is necessary when running an automatic reconciliation on the POS.
The POS uses a try/except to avoid any error, but in the case of an SQL
error, the cursor is invalidated, so the transaction fails.

opw-741677

In PostgreSQL, a field of type `integer` must be in the range
-2147483648 to +2147483647. If the user enters a lower or a larger
value, a traceback is thrown.

opw-740286

When a record is added in an x2many field with an onchange, the
onchange is only triggered once the new record is valid (i.e. when
all its required fields have a correct value).

However, there was an issue in the code checking the validity of
a record, as it iterated on all known fields of the model (instead
of those in the view), so if there were required fields that
weren't, the record was always invalid (as those fields obviously
never had a value), and thus the onchange was never done.

This wasn't a problem with embedded views as in this case, the
known fields are those in the view. But when the view isn't
embedded, all fields of the related model are known, even if only
some of them are in the view.

This was the case for example in the stock.picking form view, when
adding a line in the stock.move o2m: the onchange wasn't done and
thus, the schedule date wasn't correctly set.

Relational fields with attribute 'invisible' set to true are in
views because they are used in domains or contexts. In this case
their relational data is useless, only their ids matter. Before
this rev., their relational data was fetched anyway. More
precisely, it was the case for many2ones after a default_get, and
for x2manys with inline views, or without view (e.g. with widget
'many2many_tags').

The previous code used to create its own args array
for the search_read method, replacing the one that
was originally given to it.

This lead to silent errors since positional arguments
to this function were completely ignored in the case
of search_read.

I took this commit as an opportunity to improve a
bit on the current state of these rpc helpers.
Namely, the basic args/kwargs priority is the following (top-to-bottom):
- kwargs defined in the rpc call
- kwargs defined in the kwargs key of the params kwarg of the rpc call
- positional arguments are passed as is

For read_group and search_read methods, the priority is the following:
- kwargs defined in the rpc call
- kwargs defined in the params kwarg to the rpc call
- kwargs defined in the kwargs key of the params kwarg of the rpc call
- positional arguments are passed as is

For the /web/dataset/search_read controller, only the params kwarg is
supported, resulting in the following priority:
- kwargs defined in the rpc call
- kwargs defined in the params kwarg to the rpc call
- positional arguments are passed as is

If both a kwargs and a positional arg is given for the same parameter,
it will be sent as is to the server which will crash with a typical
"got multiple values for keyword argument" TypeError. However, in the
MockServer however, we give priority to kwargs over args in this case.

Please note that I also chose to remove unnecessary default values so
that the ones actually used are the ones from the server, not the ones
that were duplicating those in the rpc js file.

Widgets which manipulates their dom in _renderEdit were left out
from the previous implementation since this processing was done
only once when the widget is rendered the first time. If the
widget regenerates a new input upon reset for example, then it
would lack the idForLabel.

When enterprise is installed, the rendering of these widgets on
extra small screens is different, thus breaking these tests. We
need to force the test to run on normal screens.

When the online SO was already confirmed and paid, the button "Accept and pay"
was displayed instead of "View".

opw:728306

When a invoice line is create a default layout_category_sequence was created
with a value of 0, updating the value of layout_category_id.sequence instead
of fetching it.

This operation was very slow on the invoice creation wizard

opw-741517

[FIX] account: fix consistency for fiscal positions and reconcile model with their respective templates.

- Some fields were simply missing on templates, making impossible to give them a value on chart template installation.
- Added a real link between account.reconcile.model.template and its chart template instead of using account_id.chart_template_id
- Added tests for checking the consistency of those objects in the future.

Before this commit, when we moved from one line to the next, we did not
wait for the unselectRow to end.  This means that if the read (from the
unselect row) completes after the default_get, the list renderer was not
in a coherent state (currentRow was set to null), which could (and did)
cause a crash.

This was found by pressing the TAB key a few times, and editing some
values.

Also, we slightly improved the logging in the mock server.  Before this,
the responses from the mock server did not show from which route it came
from.  But in this test, we specifically make sure that the rpcs
complete in a different order, so it was not really optimal.

opw-741077
This commit closes #16616

Fix options not being passed from view declaration to JS
frontend function. If passing option 'no_create': True,
"Create" button was still visible.

Signed corporate contributor license.