Before this PR, access error could occur when the live chat operator left and the visitor refreshed the page. This occur because one can access a partner as long as there is a common channel, which might not be the case after the operator left.

Steps to reproduce the issue:
- Open two browsers: admin, visitor on the website.
- Navigate to a tracked page with the visitor (e.g. contactus and back on home page): this will create a website visitor which is a condition for the "requested_by_operator" field to be added.
- Open a chat, send a message.
- Leave with admin.
- Reload the page with the visitor.
- It's not possible to open a chat anymore due to an access error.

This PR adds a missing sudo when computing "requested_by_operator" on channel which solves the issue. This PR also adds a test to ensure that `channel._to_store` still works after the operator left, preventing other errors in the future.

task-4663990

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

[FIX] web: save a dirty record without changes

- Open a record (e.g., a project task);
- Add a tag to a `many2many_tags` field;
- Remove the previously added tag;
- The record should be dirty (the save icon should be visible);
- Click on the save icon/or click to pager next.

Before this commit, the UI does nothing. It doesn't save, or it doesn't go to
the next record if you click on the pager next. This is because even if the
record is considered dirty, because some changes have been made (adding and
removing tags), there are no changes. And a condition prevents to call the
`web_save` RPC from being called if there are no changes. If the `web_save`
RPC is not called, we do nothing.

In this commit, we change this condition so that if the `web_save` RPC is not
called, we mark the record as not dirty. When we move to another record (pager
next), we do not need to mark the current record as not dirty, but the next
record is loaded.

X-original-commit: https://github.com/odoo/odoo/commit/43fb8a45ac629c1883ca9521a8879cf19ca7538b

-----------------

[FIX] web: wait the main view reload before closing the dialog

- On a slow connection;
- In a list view (or a form view), click on a button (a view button);
- Make some changes and save;
- Make some changes in the main view;

Because the connection is slow, the main view reloads after the user has made
some changes. This causes some issues, for example : the changes may be lost,
editable list views may become uneditable, forcing the user to click again.

This happens because on the action service, the callback function (`onClose`)
is called after the dialog is closed. In the case of a view button, the
callback function will reload the main view.

This commit changes that order, we will wait for the execution of the callback
to complete before closing the dialog.

-----------------

[FIX] web: close non-last dialog


- Open multiple dialogs;
- Close a non-last dialog;
- Close all remaining dialogs with `closeAll`.

Before this commit, a dialog wasn't closed. This is because when we close a
dialog we always remove the last one from the dialog stack. Which in our case
is not the right dialog. Conversely, the offset service removes the correct
dialog (it uses the id to do this). So we have a dialog on the offset service
that is not on the dialog service stack, and a dialog on the dialog service
stack that is no longer on the offset service.

This commit removes the correct dialog from the dialog stack using the id (as
it's done in the offset service).