**1) Context**

Some reports (typically Balance Sheets) compute themselves over the whole accounting history, up to a certain date. On big databases, this is a problem, as the more the accounting grows, the slower those reports get.

To handle that, a lot of softwares (as well as Odoo, before 9.0) require creating opening entries at the beginning of every fiscal year, to just carry the balance of each account from period to period. The report would then only consider the entries of the current year, which would include the initial balance.

The problem with opening entries is that they can very easily get desynchronized from actual accounting history. You can't modify something coming before them without needing to fix them as well, and it's very error-prone. Moreover, they do have an existence into the accounting itself, cause noise, and are far from ideal for handling customer accounts. For all those reasons, they were removed in Odoo 9.0, and we are not reintroducing them.

What this commit does, however, is introducing a new mechanism that precomputes and somehow caches those parts of the reports that consider the entire history. This new mechanism is designed to be at the same time completely invisible to the users (outside of the obvious performance gains, that is), resilient, and not too technically complex (I promise).


**2) How it works**

The key idea is to cache the results of the calls to report engines. For this, we introduce a new model: account.report.snapshot. An instance of this object corresponds to the result of a single engine call.

- Snapshot generation

Snapshots are generated asynchronously, via a cron. This cron does not run periodically by itself (to avoid useless server load). Instead, it is only called via explicit triggers, when snapshots need to be refreshed. It is made to be as lightweight as possible, and will create only one snapshot at a time, retriggering itself if needed, so that other crons' execution can easily be interleaved with it.

The cron is typically triggered when modifying the lock date: a new snapshot is then created for the appropiate engine calls at that new lock date. If no snapshots were done before, we basically generate them on the last 5 years, so that period comparisons can also benefit largely from it.

Snapshots are incremental: when a new snapshot is taken, it uses the previous snapshot made for the same parameters on an earlier date, and only calls the report engine on the period that's not already covered.

- Impact on engines

A report engine (custom or standard) can be made snapshotable using a dedicated decorator. When it's declared like that, its call will be wrapped in another function that will make sure to only call the engine on the period that's not already covered by a snapshot. If the period is fully covered, the engine will simply not be called, and we hence will run no additional SQL. This makes for tremendous performance gains.


**3) Requirements and limitations**

- Not all engines are snapshotable

The computation of an engine needs to be dividable into summable "partitions" in order to allow snapshots. I other words, computing all the parts separately and then putting them together must give the same result as directly computing the full thing. These partition will be created by the cron, splitting the data by date and company (a snpashot is always made for a single company, at a given date).

If an engine's computation can be partition, but requires some post-processing using the global results, it's possible to snapshot a single subfunction instead of the engine itself. We call that a subengine. See what account_codes standard engine is doing for an example.

- Snapshots are generated for default options only

The cron only generate snapshots for the default values of the report's filters. So, if the user changes the value of one of those filters (except the date, of course), the recomputation of the report will not find any snapshot. This is deemed acceptable : the goal is not to make every single possible case super fast. We just want the basic and most common flows to be seamless.

- No multi-currency consolidation

As it is, multi-currency consolidation is not supported by snapshots.


**4) Partners, read this**

Snapshots can of course be generated by custom code as well. This could be the key to long-going performance issues in specific flows : just make an additional snapshot for the specific options dict involved in that flow.
We'll refine the feature a little more in the future to give even more flexibility to those cases.


**5) Additional changes made by this commit**

- Record Rules don't impact report computation anymore

Before this commit, and since the dawn of times (AKA, version 9), the computation of the report applied custom-made record rules created for account.move.line. This was an old implementation choice that we kept for years because we had no need of removing it, despite the fact we saw no use for it. This has now been removed: if we kept it, snapshots would have been impossible, since using them on a database with such record rules could have given wrong results (because different users could technically have needed to see different amounts for the same report, with the exact same filters).

- Custom engine signatures

All custom engine signatures change: they now use exactly the same parameters as standard engines, and not a simplified version of it anymore. The format of their return values changes in the same way. This is done so that the @snapshotable_engine decorator can be used indistinctly on both standard and custom engines.

- Engine function names

Engine functions used to require different prefixes in their names for standard and custom engine ; not anymore. Everything is now prefixed _report_engine_. It's clearer and makes the computation of snapshots easier.

task-5891829

Introduce a VoIP feature that allows users to transfer an ongoing call from one tab/device to another (e.g., from desktop Chrome to desktop Firefox or a mobile device).

The transfer follows a pull model: the target device (Device B) initiates the process via "Switch here". It requests the source device (Device A) to send a SIP REFER to its own AOR (Address of Record). The PBX then issues a new INVITE to the AOR, which Device B automatically accepts, completing the transfer.

Task-4417476

```mermaid
sequenceDiagram
    participant A as Device A
    participant PBX
    participant B as Device B
    participant C as Device C

   Note over B: create pull

    B->>A: bus: voip.call.pull/initiate
    
    Note over A: create push

    A->>C: bus: voip.call.pull/suppress_invite
   Note over C: _ignorePhoneNumbers(phone_numbers)

    A->>B: bus: voip.call.pull/pending_entries
    Note over B: store pendingEntries on pull


    B->>A: bus: voip.call.pull/pending_entries_received
    Note over A: _ignorePhoneNumbers(phone_numbers)
    A->>PBX: REFER (own AOR)

    par Invitation sent
    PBX->>A: INVITE (new call)
 Note over A: phone_number in _ignoredPhoneNumbers <br/> not shown + no ringing

    PBX->>C: INVITE (new call)
    Note over C: phone_number in _ignoredPhoneNumbers <br/> not shown + no ringing   
    PBX->>B: INVITE (new call)
Note over B: pendingEntries matches phone_number <br/>auto-accept + no ringing

   end

    B->>PBX: 200 OK

    PBX->>A: REFER 202 Accepted
    Note over A: onAccept -> hangup()
    A->>PBX: BYE

B->>A: bus: voip.call.pull/result
Note over B: display stats + delete pull
Note over A: display stats + delete push

```

Task-4417476