Issue:
======
Image changes aren't auto saved.

Steps to reproduce the issue:
=============================
- Add cover snippet and text-image snipets
- Change cover image or the image in the text-image snippet
- Don't click anywhere after that
- Switch tab to A/B testing for example
- Go back to mail body
- The image changes aren't saved

Origin of the issue and solution:
=================================

When we choose an image from the media dialog, we loose the focus from
the editable which means `onWysiwygBlur` is not called and as
consequence `commitChanges` isn't called too.

Since the flow of the destroy and the `commitChanges` in `onWysiwygBlur`
are in parallel, the following happens:
- We don't update the value in the blur flow because we will wait for
  some promises which may take some time and the component gets
  destroyed and we never call the `updateValue` at the end of the
  function.
- Now in the `commitChanges` coming from `onWillUnmount` we need to pass
  the `urgent` flag in mass_mailing too.

opw-3947516

Forward-Port-Of: odoo/odoo#172312

Currently when importing an order from sale to pos, if the price was set manually, changing the partner associated with the order will set back the price to the original product sale price.

Steps to reproduce:
-------------------
* Make a new quotation in **sales**
* Change the unit price of a product
* Confirm quotation
* Open the pos shop session
* Import the newly created quotation to be settled
* Change the partner
> Observation: The price set manually changes to the product sale price

Why the fix:
------------
When changing the partner of a sale order we compute all the line that have to recompute their prices:
https://github.com/odoo/odoo/blob/57f1b0bd502938a6d50244896e71df73705584b5/addons/point_of_sale/static/src/js/models.js#L2918-L2920

We see that when we settle an order, `price_manually_set` is set to false. In this example, if we set it to true it would solve the issue but we cannot use it, see with https://github.com/odoo/odoo/commit/70668ee3c3e2c1dd213903b44f4d36cc8ac9fa29 .

Instead what we can do is to use `price_automatically_set` and set it to true. This does not undo the previously mentionned commit and fixes this current issue. This variable was created in https://github.com/odoo/odoo/commit/067299539116b55a449f022706c395dda2177829

opw-4001497

Forward-Port-Of: odoo/odoo#172205

This is a complement to previous fix https://github.com/odoo/odoo/commit/649a7f185dca806af3b3d54a1e4390b9baff79c6 in which the use case where both companies have "Round Globally" set as "Rounding Method" was not handled.

**Steps to reproduce:**
- Install Sales & Accounting
- Create a second company with a different currency (e.g. AED) than the first one (e.g. USD)
- Configure the rounding factor of the currency of the second company to 1.000000
- Configure the default company of the current user to the second company
- Switch to the second company
- In Accounting settings, set "Rounding Method" to "Round Globally"
- Switch to the first company
- In Accounting settings, set "Rounding Method" to "Round Globally"
- Create a SO:
  * Customer: [any]
  * Order Lines: [any line with a tax]
- Save the SO
- Edit the SO by changing the price unit of the product !!! Make sure that the tax amount has a decimal part
- Save the SO

**Issue:**
In the chatter, the note about the new value of the tracked field Total is different from the Total value shown in the SO. Also, in Customer Preview, the total to pay shown on the upper-left of the page is different than the total shown in the SO details.

opw-3814058



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

Forward-Port-Of: odoo/odoo#174560

`stdnum` library incorrectly sets `zeep` `Transport` timeout, resulting in
some requests hanging for 15 minutes. With this monkeypatch the timeout
will be set correctly. The monkeypatch is a full copy of the original
code except for adding `operational_timeout` to the `Transport` initialization.

The monkeypatch can be removed when https://github.com/arthurdejong/python-stdnum/issues/444 is resolved and the version is upgraded.

Related zeep github issue: https://github.com/mvantellingen/python-zeep/issues/140
This fix was already merged but reverted due to an unexpected side-effect:
Original commit: https://github.com/odoo-dev/odoo/commit/11062f6f77ed1292c6db9d64985dddeb46d354c8
Revert: https://github.com/odoo-dev/odoo/commit/de9df2ba5c15d399d6906ef54f3e4ac9f063a175

The issue originated from a dependency issue in the `zeep` library in [Ubuntu 22.04](https://packages.ubuntu.com/jammy/python3-zeep).
The `python3-platformdirs` dependency is missing in there, yet it is used in that version of `zeep`. This missing dependency used to be hidden by the [chains of `try ... except ImporError` of `stdnum`](https://github.com/arthurdejong/python-stdnum/blob/d5666b8bfe379688a38bb0fd6764a8c536dd3c75/stdnum/util.py#L254).
That means that it's another import from the chain that was used. So to reduce the possibility of introducing a similar bug and catch such errors, the original code from `get_soap_client` of `stdnum` has been fully copied.

opw-3980718

Forward-Port-Of: odoo/odoo#174199
Forward-Port-Of: odoo/odoo#173359