This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.

From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:

- models, which are logical entities that depict the client-side state of
  messaging as a whole.
- components, which are in charge of displaying information from models.

This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.

Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249

Task-1914207

This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.

closes odoo/odoo#39023

Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>

This commit adapts tests following recent changes on the helpers.
The main change is that addMockEnvironment (and all functions using
it) are now async, as they need to wait for services to be started.

Use of the new control panel helpers to increase consistency and change the assertions
according to the new DOM/behaviour (e.g. components removed instead of turning invisible).

Part of task 2196029

Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>

The test may fail non-deterministically from intercepting an
heartbeat in the local storage. Only a document thread window fold
state change from the local storage should be intercepted.

Closes #43072

Before this commit, there could be an infinite loop when changing
the chat window state of a document chat window.

This is caused when mutiple tabs overwrite the chat window state
with a different value everytime, resulting to an infinite loop.
Accross multiple tabs, `setItem` and `onStorage` are not synchronous.
That's why tabs should communicate through local storage events
instead of actual value in the local storage.

To illustrate the issue, suppose there are 2 tabs (T1 and T2) with
one document chat windows (C) and the following user interactions:

     -  T1 and T2 both have C open
     -  on T1, user folds C
     -  on T2, user folds C

Now let's add an example of local storage (LS) logics that could
apply from above example:

     -  T1 and T2 both have C open
     -  on T1, user folds C
    [1] T1 writes 'C folded' in LS
     -  on T2, user folds C
    [2] T2 writes 'C folded' in LS
    [3] T2 detects 'C folded' in LS (from [1])
           => T2 writes 'C folded' in LS
    [4] T1 detects 'C folded' in LS (from [2])
           => T1 writes 'C folded' in LS
    [5] T1 detects 'C folded' in LS (from [3])
           => T1 writes 'C folded' in LS
    [6] T2 detects 'C folded' in LS (from [4])
           => T2 writes 'C folded' in LS
     etc...

This scenario could have been easily prevented by not writing on
local storage when the chat window state has not changed. However,
this wouldn't fix this scenario that also introduces an infinite
loop:

    -  T1 and T2 both have C open
    -  on T1, user folds C
   [1] T1 writes 'C folded' in LS
    -  on T2, user folds C
   [2] T2 writes 'C folded' in LS
   -   on T2, user unfolds C
   [3] T2 writes 'C unfolded' in LS
   [4] T2 detects 'C folded' in LS (from [1])
          => T2 writes 'C folded' in LS
   [5] T1 detects 'C unfolded' in LS (from [3])
          => T1 writes 'C unfolded' in LS
   [6] T2 detects 'C unfolded' in LS (from [5])
          => T2 writes 'C unfolded' in LS
   [7] T1 detects 'C folded' in LS (from [4])
          => T1 writes 'C folded' in LS
   [8] T2 detects 'C folded' in LS (from [7])
          => T2 writes 'C folded' in LS
   [9] T1 detects 'C unfolded' in LS (from [6])
          => T1 writes 'C folded' in LS
   etc...

This commit fixes the infinite loop issue:

  - by turning local storage read during cross-tab communication into
    local storage event read instead. This should prevent race
    conditions based on read/write operations in local, since their
    order is not guaranteed accros tabs.
  - by isolating document chat window state to their own local
    storage entry. This should prevent a tab from notifying a chat
    window state that it didn't change, which may also result in
    an infinite loop.

Some tests were adapted from the changes above. Also, some tests did
pass thanks to local storage being mocked by a ram storage: the
handler `_onStorage` should have been called, but it didn't because
it was registered on the actual local storage instead of the ram
storage. In order to make tests pass again, the following additional
changes were required:

  - Cross-tab bus service now exports the unique tab ID with
    `getTabId`.
  - document thread entries in local storage now track the tab ID, so
    that self-tab ignore their own local storage writes.

Task-Id 2034997

Closes #36177

closes odoo/odoo#35119

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Before this commit, most new messages added to the mail manager were
handled as if recently posted from a document thread. As a result, it
was frequently setting a new item in the local storage to notify
other tabs from these new messages.

The intent of this behaviour is to notify other tabs of newly posted
messages in a document thread, without using a longpolling
notification. That means this logic should only apply on messages
that have been recently posted on a document thread.

Sometimes, this issue was breaking the local storage on Firefox.
It showed the error message "Quota Exceeded Error" whenever `setItem`
was used, even when items were removed beforehand. The capacity of
the storage was only a few Kbs on this domain, far from reaching the
maximum capacity. We think that this error comes from the concurrent
`setItem` on multiple tabs, but this is very hard to reproduce.

This commit fixes the issue by limiting the `setItem` to the tab
that really posted the message. Tests have been adapted in order to
pass only with this fix.

Before this commit, most new messages added to the mail manager were
handled as if recently posted from a document thread. As a result, it
was frequently setting a new item in the local storage to notify
other tabs from these new messages.

The intent of this behaviour is to notify other tabs of newly posted
messages in a document thread, without using a longpolling
notification. That means this logic should only apply on messages
that have been recently posted on a document thread.

Sometimes, this issue was breaking the local storage on Firefox.
It showed the error message "Quota Exceeded Error" whenever `setItem`
was used, even when items were removed beforehand. The capacity of
the storage was only a few Kbs on this domain, far from reaching the
maximum capacity. We think that this error comes from the concurrent
`setItem` on multiple tabs, but this is very hard to reproduce.

This commit fixes the issue by limiting the `setItem` to the tab
that really posted the message. Tests have been adapted in order to
pass only with this fix.

note: backport of 12.2 4bde721f9

opw-2031960
closes #35588

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Part of task 1896658

Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>