----------------------
 Summary
----------------------

The purpose of this commit is to improve the JS code of the `mail` module.
It applies the new coding guidelines and makes some changes on the design
of some modules, such as the old ChatManager module.

Here is a short summary of the changes that have been made:

  1. New coding guidelines
    - snake_case to camelCase
    - prefix private attributes and methods with '_'
    - jsdoc on most methods
    - one class per module
  2. Rename/Merge some classes
    - 'chat manager' becomes 'mail manager' (internal) and 'mail service' (external)
    - 'chat window manager' is now included in mail manager
    - 'thread' widget now named 'thread widget'
  3. New model abstraction for mail objects:
    - modules 'mail.model.*'
    - modeling:

                    0..1    0..1        *     *
      ThreadWindow  <------>  Thread <-------> Message
                              /    \
                             /      \
              Thread With Cache     Document Thread
               /      |       \
              /       |        \
        Mailbox    Channel    Support Channel
                      |
                      |
                      DM

    - Thread: the superclass of threads.
    - ThreadWindow: the window component of a thread.
    - Message: mail objects representing messages.
    - Thread With Cache: threads that can be used with search view (Discuss app compatible).
    - Document Thread: represents the thread part of a chatter.
    - Mailbox: represents what was previously called 'static' channel, e.g. 'Inbox'.
    - Channel: mail objects representing channels, including livechat.
    - DM: special kind of Channel for 1:1 communication in the backend.
    - Support Channel: special channel for im_support module.

  This new modeling approach let us easily add features on all threads, such as the
  possibility to put any thread in a small window.

----------------------
 Known issues
----------------------

 [Already Present in Master]

    1. When the Discuss app is in the background with 'Inbox' as the selected
       Thread, when clicking on a document thread preview in the messaging menu
       of the systray, the rainbow man appears.

    2. When a document with the chatter is in the background, when receiving an
       inbox notification from this document thread, the document thread is
       automatically marked as read, which removes the notification right away.

    3. Sometimes, opening a DM window from the "blank" thread window does not work.

    4. Reply-to feature on Inbox is not working: no message is sent in the document
       thread.
    5. On the first login of admin user with demo data, the inbox counter is wrong
       (it displays 6, instead of 3).

       Explanation after investigation:

        > On page load, it fetches the correct number of Inbox messages (3),
          but the server notifies of 3 needaction messages right away,
          so it wrongly assumes these are new needaction messages.
        > Not possible for web client to detect that these messages should not
          increment the Inbox counter while keeping same API.

    6. Notifications for new document thread messages only work when the user sets
       'handle with Odoo' for the Notification Management in the preferences.

        > due to notifications on the longpoll bus for document thread
          messages that come from needaction notifications.
        > requires server-side changes to send notification on the longpoll
          bus to mentionned user.

  [New]

    7. When receiving a message on a unjoined channel, thread window flickers
       ('open' > 'close' > 'open')

        Explanation after investigation:

          > JS logic:

            a) On auto-join, ask server to join the channel and get channel infos.
            b) The info tells the channel is not detached, but JS code makes decision
               to detach it, and tells server the channel is now detached.
            c) From (a), server notifies on longpoll bus the state of channel, which is
               not detached. The web client thinks that the window state of the channel
               has been changed somewhere else, and the channel is now closed.
            d) From (b), server notifies on longpoll bus the state of channel, which is
               detached. The web client opens the thread window of this channel.

          > The flicker didn't occur before refactoring because the web client was only
            updating the model of channel when it receives the longpoll notification.
          > Server behaviour on 1st longpoll notification is necessary for cross-tab
            synchronization for channel window state.
          > New design implies that model and view should be synchronized, hence the
            issue now.
          > Solution: remove server-side thread window synchronization and replace with
            client-side synchronization.

----------------------
 Hacks
----------------------

The module `im_livechat` now uses mail objects that are compatible with Message
and Window objects:

      Modeling for messages:

                             AbstractMessage
                              /           \
                             /             \
                    LivechatMessage      Message

      - AbstractMessage: message compatible with the thread widget.
      - LivechatMessage: message used by im_livechat.
      - Message: message used with the mail manager.

      Modeling for thread windows:

                          AbstractThreadWindow
                              /           \
                             /             \
                    LivechatWindow    ThreadWindow

      - AbstractThreadWindow: behaviour share between all types of thread windows.
      - LivechatWindow: window used by im_livechat.
      - ThreadWindow: window used with mail_manager.

The reason for these hacks are twofold:

  1. Use the thread widget in the frontend and livechat external lib bundles.
  2. Do not have a dependency with the mail manager in the frontend and external
     lib bundles.

If document viewer is opened from chat window and when document viewer is opened then focus 
remains on it's modal, pressing escape should set focus back to chat window's input element,

if file selecor dialog is opened and if user press ESCAPE on file selector dialog to cancel file selector 
dialog then it should not close chat window instead it should set focus on chat window input and on 
second ESCAPE key chat window should be closed
also increase z-index of document viewer dialog so image remain on top of cht window

OPW: 1777937

This commit improves the JS code of the mail module,
which comes maily from the new coding guidelines
and the addition of "JS services".

JS services are important objects that do not fit
well in the component tree, such as chat_manager
or ajax.

The benefits of JS services are improved readability
of the code, reduced coupling, and more testable
modules. In particular, discuss was hard to

Summary of the changes:

- ClientAction has been renamed into Discuss
- Clear instantiation of chatManager
- New coding guidelines in most mail modules
- JS Services can interact with each other
- Chat Manager and Window Manager are services
- Window Manager renamed to Chat Window Manager
- bus.bus is now encapsulated in Bus Service (a service)
- The test infrastructure has been tweaked with JS Services
- Chat Mixin has been removed

A future improvement would be to translate some 'trigger' into 'trigger_up'.

In Less, the size_class XXS is defined and used in media queries.
This rev. adds it in JS for sake of consistency.

Code in addons comparing the size_class needed to be adapted due
to the new XXS size_class.

Moreover, we now use the helper 'config.device.isMobile' everywhere
we should, instead of manually comparing the size_class.

Finally, we changed the way the config.device has to be specified
in the test environment. From now on, only the size_class should be
set, and the isMobile flag is computed automatically.

Revision on c778de44c7cd9b7ef5a9a91738164ab0ebd0ca06
The changes on chat_window are wrong, because the
composer uses an 'input', instead of a 'div'.

As a result, it was not possible to send messages
over im_livechat from the website.

This was not the case on the webclient: chat_window
is enhanced with extended_chat_window, which replaces
the composer with 'div', hence the changes are correct.

When someone mentions another person in discuss/chat window, the
mentioned name was displayed just as a text, which may be unclear.  With
this commit, we display mentions with the same style as mentions in a
message.

To do that, the main idea is to change the input by a div with
contenteditable set to true.  This allows us to add <a>...</a> inside.

The `isMobile` variable was defined at the right place (`config.device`)
but was set at the wrong place (`config`).

Thank you for making me author of all the `isMobile` lines by
the way... :)

Before this commit, clicking on the button opened the emoji popover
then closed it immediately. This was because of a handler which said
that clicking on any part of the composer should focus the input
element. This is indeed required when the UI is blocked (thanks to
the `blockUI` function). Solution is to not force this focus when
clicking on any composer's button element.

To prevent breaking those two behaviors (blockUI focus and emoji), two
tests were implemented.

- Extract mobile specific code for the client action to a specific
  file
- Massive clean of less rules
- Unify channels preview of the systray dropdown and the mobile UI
  of Discuss
- Ensure to only load the last message of each channel in mobile,
  as this is not used in desktop (unless the user opens the systray
  menu)
- Make livechat available in Discuss mobile UI