Steps to Reproduce:

  - Install 'account' module
  - Go to Settings and set a token for Google Drive
  - Activate Google Spreadsheet
  - Go to Invoicing -> Invoices
  - Under Search bar, click on Favorites -> Add to Google Spreadsheet

Issue:

  A spreadsheet does open but with no data (no formula or config).

Cause:

  The V3 API we were using was turned down in August 2021 and therefore
  not able to use the api to write on the spreadsheet.
  https://cloud.google.com/blog/products/g-suite/migrate-your-apps-use-latest-sheets-api)

Note: In case that the system parameters `​google_drive_client_id` and
`google_drive_client_secret` has been changed (and therefore also the
default templates), it must be ensured that the `client` has the
Google Sheet API (v4) activated and the scope
`[https://www.googleapis.com/auth/spreadsheets`](https://www.googleapis.com/auth/spreadsheets%60) set.

API activation and configuration available here :
https://console.developers.google.com/apis/dashboard?project=[PROJECT]
https://console.developers.google.com/apis/credentials/consent/edit?project=[PROJECT]
**[PROJECT]** : Google project that will be linked to `​google_drive_client_id`.

opw-[2633951](https://www.odoo.com/web#id=2633951&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#84436
Forward-Port-Of: odoo/odoo#83856

Description of the issue/feature this PR addresses:
- Create a sale.order with a product with an optional product
- Confirm order A
- Copy this order A, a new order B is created
--> Issue: the new line of order B are linked with an line of order A

@tivisse @tde-banana-odoo 

Note the best solution is (maybe for master):

```python
class SaleOrder():
    order_line = One2many(copy=False)
   
    def copy(self, default=None):
        new_order = super().copy(default)
        map_line = {}
        map_line_linked = {}
        for line in self.order_line:
            new_line = line.copy({'order_id':  new_order.id}
            map_line[line] = new_line
            map_line_linked[new_line] = line.linked_line_id
        for line in new_order.order_line:
            linked = map_line_linked.get(line)
            if linked:
                line.linked_line_id = map_line[linked]
        return new_order
```
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#84431
Forward-Port-Of: odoo/odoo#83536

This generally improves the performance of `convert_inline` so `mass_mailing` can load and save faster.

Tested on the saving of the "newsletter" template on runbot, the conversion is about **13.5x faster** with this PR than before (from 2.99s to 220.91ms).

- Some tests depended on a variable to be defined, which was only defined in other tests.
- `__extraAssetsForIframe` had been kept in `mass_mailing` and `web_editor` for historical reasons but was not used anymore. This removes it.
- `web.assets_frontend` was called in `wysiwyg_iframe_editor_assets` _and_ in `iframe_css_assets_edit`. As a result, they were loaded twice in edit mode.
- This batches all writes in the `classToStyle` method of `convert_inline` so as to minimize layout thrashing and therefore improve performance.
- This batches all writes in the `formatTables` method of `convert_inline` so as to minimize layout thrashing and therefore improve performance.
- `convert_inline` used to do some style adaptations that seem to only have been needed due to improper css assets loading, which was fixed in a previous commit.
- Since some css was loaded twice, when parsing rules, we grouped similar rules in order to minimize the amount of rules on which to iterate during conversion, so as to improve performance. This is not needed anymore now css is loaded only once, so we can remove this extra processing.
- This improves performance of `classToStyle` by first selecting which nodes and which rules will be concerned. When parsing the css rules, we computed their specificity and normalized their styles one by one. This applies these processes only on the concerned rules, all at once.
- Rules used to be applied in the DOM sequencially, in traversal order. This is slow and confusing to debug. Meanwhile, most functions had been adapted to process the rules in a simple loop on the concerned nodes. This commit does that for `classToStyle`, the last remaining function that wasn't doing it yet, and removes the utility function `applyOverDescendants` altogether.
- This refactors the cache of cssRules.
- jQuery was used extensively in `convert_inline`, slowing it down by a factor of more than 2. This replaces all use of jQuery with vanilla javascript so as to improve performance significantly.
- The conversion of the comparison snippet for mail compatibility involves heavy changes in the html. In order to preserve the style, some style changes were needed as well. This change to the style of cards allows us to restore the border around the snippet.
- The final mail to be sent will have to use a mail-safe font everywhere so we can't allow other fonts to be applied in some elements. Because of the way the css was declared, we still had other fonts on some elements, like .btn. As a result, we had a different look between readonly and edit modes.
- Icons converted to images were improperly aligned because as inline elements their vertical-align style property used their first block ancestor as reference.

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

Forward-Port-Of: odoo/odoo#84465
Forward-Port-Of: odoo/odoo#84088

**Description of the issue/feature this PR addresses:**

**Use Case:**

Google Spreadsheet Odoo Script Access (XML-RPC API), ~~not sure which change triggered this behavior, but~~ there was and is a point of failure in case no lang context key is defined.

EDIT:
Using the wrong configuration for the base url in Google Spreadsheets like https://yourdomain.tld/ instead of https://yourdomain.tld will trigger this error...

**Current behavior before PR:**
<details>
  <summary>Traceback</summary>

```
Error on request:
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/werkzeug/serving.py", line 270, in run_wsgi
    execute(self.server.app)
  File "/usr/local/lib/python3.6/site-packages/werkzeug/serving.py", line 258, in execute
    application_iter = app(environ, start_response)
  File "/opt/odoo/custom/src/odoo/odoo/service/wsgi_server.py", line 140, in application
    return ProxyFix(application_unproxied)(environ, start_response)
  File "/usr/local/lib/python3.6/site-packages/werkzeug/contrib/fixers.py", line 152, in __call__
    return self.app(environ, start_response)
  File "/opt/odoo/custom/src/odoo/odoo/service/wsgi_server.py", line 117, in application_unproxied
    result = odoo.http.root(environ, start_response)
  File "/opt/odoo/custom/src/odoo/odoo/http.py", line 1287, in __call__
    return self.dispatch(environ, start_response)
  File "/opt/odoo/custom/src/odoo/odoo/http.py", line 1257, in __call__
    return self.app(environ, start_wrapped)
  File "/usr/local/lib/python3.6/site-packages/werkzeug/wsgi.py", line 766, in __call__
    return self.app(environ, start_response)
  File "/opt/odoo/custom/src/odoo/odoo/http.py", line 1456, in dispatch
    result = ir_http._dispatch()
  File "/opt/odoo/custom/src/odoo/addons/website_sale/models/ir_http.py", line 15, in _dispatch
    return super(IrHttp, cls)._dispatch()
  File "/opt/odoo/custom/src/odoo/addons/website/models/ir_http.py", line 172, in _dispatch
    response = super(Http, cls)._dispatch()
  File "/opt/odoo/custom/src/odoo/addons/auth_signup/models/ir_http.py", line 19, in _dispatch
    return super(Http, cls)._dispatch()
  File "/opt/odoo/custom/src/odoo/addons/web_editor/models/ir_http.py", line 21, in _dispatch
    return super(IrHttp, cls)._dispatch()
  File "/opt/odoo/custom/src/odoo/addons/utm/models/ir_http.py", line 29, in _dispatch
    response = super(IrHttp, cls)._dispatch()
  File "/opt/odoo/custom/src/odoo/addons/http_routing/models/ir_http.py", line 469, in _dispatch
    cls._add_dispatch_parameters(func)
  File "/opt/odoo/custom/src/odoo/addons/website/models/ir_http.py", line 211, in _add_dispatch_parameters
    super(Http, cls)._add_dispatch_parameters(func)
  File "/opt/odoo/custom/src/odoo/addons/http_routing/models/ir_http.py", line 405, in _add_dispatch_parameters
    nearest_ctx_lg = not is_a_bot and cls.get_nearest_lang(request.env.context['lang'])
KeyError: 'lang'
```

</details>

**Desired behavior after PR is merged:**
No Traceback

Info: @wt-io-it

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

Forward-Port-Of: odoo/odoo#83880

Description of the issue/feature this PR addresses:

While calling `_stock_account_prepare_anglo_saxon_out_lines_vals`, the line 
`credit_expense_account = accounts['expense'] or self.journal_id.default_account_id` 
can cause a 'Expected singleton' error. During upgrades from v13 and earlier, the value used for `accounts['expense']` is always `None`. If the recordset in `self` contains more than one record, the error will happen.

By replacing `self` with the iteration object `move`, this error is averted.

Current behavior before PR:

The error happened during an upgrade from v13. Since the value assigned to `accounts['expense']` doesn't exist in that version, it goes to `self.journal_id.default_account_id` to grab it. If `self` has more than one record, the error happens.

Traceback:
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1199, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 475, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/src/odoo/14.0/odoo/modules/migration.py", line 180, in migrate_module
    migrate(self.cr, installed_version)
  File "/tmp/tmpae3wx5o6/migrations/account/saas~13.4.1.1/end-09-payment-refactoring.py", line 618, in migrate
    util.iter_browse(env["account.move"].with_context(**ctx), ids, chunk_size=1024).action_post()
  File "/tmp/tmpae3wx5o6/migrations/util/orm.py", line 197, in caller
    return [getattr(chnk, attr)(*args, **kwargs) for chnk in chain(it, self._end())]
  File "/tmp/tmpae3wx5o6/migrations/util/orm.py", line 197, in <listcomp>
    return [getattr(chnk, attr)(*args, **kwargs) for chnk in chain(it, self._end())]
  File "/home/odoo/src/odoo/14.0/addons/sale/models/account_move.py", line 14, in action_post
    res = super(AccountMove, self).action_post()
  File "/home/odoo/src/odoo/14.0/addons/account/models/account_move.py", line 2715, in action_post
    self._post(soft=False)
  File "/home/odoo/src/enterprise/14.0/l10n_mx_edi_landing/models/account_move.py", line 26, in _post
    return super()._post(soft)
  File "/home/odoo/src/enterprise/14.0/l10n_mx_edi/models/account_move.py", line 456, in _post
    return super()._post(soft=soft)
  File "/home/odoo/src/odoo/14.0/addons/sale/models/account_invoice.py", line 75, in _post
    posted = super()._post(soft)
  File "/home/odoo/src/odoo/14.0/addons/purchase_stock/models/account_invoice.py", line 171, in _post
    return super()._post(soft)
  File "/home/odoo/src/enterprise/14.0/account_reports/models/account_activity.py", line 75, in _post
    return super()._post(soft)
  File "/home/odoo/src/odoo/14.0/addons/stock_account/models/account_move.py", line 49, in _post
    self.env['account.move.line'].create(self._stock_account_prepare_anglo_saxon_out_lines_vals())
  File "/home/odoo/src/odoo/14.0/addons/stock_account/models/account_move.py", line 158, in _stock_account_prepare_anglo_saxon_out_lines_vals
    'account_id': credit_expense_account.id,
  File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 3821, in __get__
    raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: account.account(1383, 38, 30)
```

Desired behavior after PR is merged:

During normal use behavior should be the same. This particular upgrade should be fixed.


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

Forward-Port-Of: odoo/odoo#83739

When the user has the planning and Sales apps installed and created an open shift
(a shift without any resource set) and he published and sends the planning to his
employees, the employees can see the SOL linked to this shift. However, if the
user installs the Project app, the `project_forecast` module is installed to make
the bridge between the `Planning` and `Project` apps. This module overrides the template shown
to the employees to see the planning. This override erases the SOL field shown in this template.

Steps to reproduce:
Install Planning and Sales apps
Go to the planning app
Add a new shift and set an SOL
When we are in the Gantt view of the Planning app, clicks on the Publish button
and send the planning to an employee
Check the mail sent and go to the mail sent with the planning and click on the
link to redirect to the planning. Normally we see the SOL linked to the shift
Install the Project app
Go back to the planning URL sent to the employee

Actual Behaviour:
The SOL linked to the shift is no longer visible.

Expected Behaviour:
The SOL linked should be visible in that template.

closes #23705
task-2742510

Forward-Port-Of: odoo/enterprise#23705