Main issue:

Prior to this commit, updateValue would guarantee that `body_arch` and
`body_html` were always updated in sync (to avoid an inconsistent state where
the user thinks they updated the mailing, and they see the new html in the
editor, but the email html is obsolete and would be sent as is).

However this caused another issue, that the user would lose their work when
switching tab in the Notebook, because computing the `body_html` may be slower
than the view patch to switch tab (`updateValue` is interrupted). In such a
case, neither `body_arch` nor `body_html` was updated on the record, and when
the user comes back to edit them, they see that all changes were lost.

To prevent this, a new strategy is adopted:
- `body_arch` is now updated as soon as possible to save the latest user
  changes
- `body_html` is set to an empty string to avoid inconsistencies, and in order
  to trigger `convert_inline` automatically the next time the
  `mass_mailing_html_field` is instanced without any user action.
- after `convert_inline`, if `updateValue` was not aborted, the record is
  updated again with the new value for `body_html`

Minor issues:

1) Prior to this commit, the iframe would flicker during `convert_inline`
because it was done inside that very iframe, and the `convert_inline` needs a
specific width (1320px) for it to work properly, meaning that if the iframe was
not at that specific dimension, it was resized temporarily for that process.
This commit introduces hooks to execute the `convert_inline` process in a
separate iframe, outside of the user view, which removes this flickering.

2) Prior to this commit, assets for readonly/basic editor/builder were all
loaded inside the iframe, and then toggled on/off depending on which were
needed. Since the `convert_inline` process is moved in another iframe, it's as
good time as any to deprecate this toggling (as it could be a bit unreliable and
could cause some flickering when unloading/reloading the style). There is now a
separate asset bundle for the 3 use case, and only one of them is loaded per
iframe depending on the needs.

3) Prior to this commit, `body_html` was hard-coded as a dependency of the
`mass_mailing_html_field`, and that dependency lacked the `required` attribute,
which should depend on the value of `body_arch`. The dependency is now added in
the related views, and the field is now generic. This also prevents the user
from leaving the view if `convert_inline` could not be completed successfully.

4) Prior to this commit, switching to another view through `doAction` could
throw an error if the field was dirty, as the `form view` would be destroyed
before `commitChanges` had the time to be completed. Now, `commitChanges`
promise is properly awaited by the `action_service` if the field is dirty before
`doAction` (unless `forceLeave` is true).

5) Prior to this commit, the record was updated through a `blur` event on the
iframe window. However, it means that every time the iframe looses focus when
the users interacts with the builder, a popover or the form status indicator,
that blur event would fire, triggering the `convert_inline` process. This commit
reduces the amount of such updates by only triggering the update outside of
these elements, as we don't need to update the record value while the user is
still actively editing the mailing.
Blur handlers/props are deprecated with this commit and will be removed further
down the line.

6) Ensure that in the rare case where a `html_field` value is exactly the same
on different records, the `html_field` state key is updated (triggers a
wysiwyg/mass_mailing_iframe reset).

7) Remove an erroneous part in `onWillUpdateProps` of `mass_mailing_html_field`
which could display the theme selector again on the same record just after
selecting a theme if props were updated.

8) Ensure `withBuilder` getter of `mass_mailing_html_field` properly reads the
state activeTheme every time it is used (if it does not, it could cause issues
with the reactivity, since reading on the state is required for a property
subscription).

9) Remove a useless `onWillUpdateProps` of `mass_mailing_iframe` which was never
used because when `props.showCodeView` changes, the iframe is always destroyed,
so there is no need to update its state.

10) Deprecate usage of `<meta http-equiv="X-UA-Compatible" content="IE=edge"/>`,
to be removed further down the line, as it is useless in the modern web.

11) Ignore errors during a builder "Operation" that was not finished before the
editor was destroyed. In `mass_mailing`, the editor is expected to be
destroyable synchronously to work inside an Odoo view, unlike in `website`.
What's already in the DOM just before destruction will be updated on the
`record`, and the rest of the operation will be lost. However, an attempt is
made to wait for ongoing operations at the start of the
`HtmlField.commitChanges`.

12) Ensure correct visibility option state
Prior to this commit, the `dataAttributeChangeAction` selected item depended on
the domain value computed during the last template rendering, compared to the
current edited element value. The issue is that when an edited element receives
a new `data-filter-domain`, the selected options are evaluated before the
component can register the new domain in its state, so the wrong values are
compared. In this particular case, since we only need 2 values (on/off), an
acceptable trade-off is to choose the selected item ("always visible" vs
"conditionally") based on the Boolean value of the attribute.

13) Remove deprecated assets toggle test
The toggle assets feature was deprecated in a prior [commit1].
The test is removed as its outcome is non-deterministic, because it depends on
the `target` property of `event` returned as a promise resolution value by
`loadBundle`, however the browser can set that target to `null` after the event
was dispatched, so relying on the target value to keep track of the inserted
link is not reliable.
Since that `toggle` feature is not used anymore, it is not needed to run a test
for it. The feature will be removed in the latest `dev` branch.

[commit1]: https://github.com/odoo/odoo/commit/a0aa581636e257894c6c7e87c3793edebecad303

14) Prevent crash on commitChanges if editor is not ready
Prior to this commit, various checks in `commitChanges` did not take into
account that the editor could be instanced but not ready yet (meaning that
plugins are not available, and it is not possible to extract the editable
content).
This commit ensures that `commitChanges` can not crash if called when the editor
is not ready.

15) Properly keep track of dirtiness
mass_mailing changes related to [commit2], which added a way to keep track of a
specific change handled during one `commitChanges` call. The field should stay
dirty if it received changes during a `commitChanges` execution.
In mass_mailing specifically, there were 2 other situations with invalid
tracking of dirtiness:
a) A new record with no change could not be discarded as it was incorrectly
marked as dirty since the `inlineField` value is "".
After this commit, the field is marked as dirty only if the edited field value
is not "" while the `inlineField` value is "", which is the problematic
situation where both values are desynchronized. A new record with both values at
"" is not marked as dirty anymore.
b) Setting a new theme in mass_mailing did not communicate properly with the
relational model about dirtiness.
After this commit, using `setThemeHTML` triggers `onChange`, and the record
update properly tracks that change to communicate with the
`FormStatusIndicator`. The field `isDirty` property stays at `true` though,
because it still needs to execute `convertToEmailHtml` to compute the
`inlineField` value, and it needs the `editor` for that. A `commitChanges`
occurs `onEditorReady` to execute this computation, at the end of which the
field is finally set as not dirty.

[commit2]: https://github.com/odoo/odoo/commit/378580735c785bdcf8b184342834d2b3ddaaaedd

16) Prevent crash with null selection
`document.getSelection()` returns `null` when the selection is not in the
document. However the selection plugin `isSelectionInEditable` function only
support a selection object or `undefined` as an argument, and will crash with
`null`.
This commit ensures that a valid value is provided to the plugin function to
prevent crashes where the selection is moved outside of the `mass_mailing`
iframe before `normalize_handlers` execution.

task-5976348

Forward-Port-Of: odoo/odoo#252571
Forward-Port-Of: odoo/odoo#250883

Problem:
When content is added to the editor, icons are not surrounded by
`feff`s.

Cause:
The selector used to pad elements with `feff`s relies on
`o-paragraph`, which is added during normalization.
However, `BaseContainerPlugin.normalize_handlers` runs last, so when
`FeffPlugin.normalize_handlers` executes, it cannot find icons through
`selectors_for_feff_providers` because the expected paragraph-related
parent is not yet in place.

Solution:
Execute `FeffPlugin.normalize_handlers` immediately after
`BaseContainerPlugin.normalize_handlers`, ensuring the DOM structure is
ready before attempting to add surrounding `feff`s.

Steps to reproduce:
- Add an icon.
- Reload the page.
- Do not make any changes (so normalization is not triggered again).
- Inspect the icon and observe that it does not have surrounding
  `feff`s.

task-5960097

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

Forward-Port-Of: odoo/odoo#252278
Forward-Port-Of: odoo/odoo#250855

Currently, if we try to update the existing `l10n_it_edi_attachment_file` with the signed data received during the submission of an invoice (Invoices for Italian Public Administration businesses must be signed, handled on the IAP side), it fails.

The problem is that in this specific flow, the 'attachment' variable contains a binary rather than attachment_data.

Unfortunately, I could not find a complete flow to reproduce the issue, as there is no flow that sends an invoice to SdI while the l10n_it_edi_attachment_file variable is already set in the move, except maybe via manual import of an attachment into the invoice.

Expected flow:
- User creates a move with `l10n_it_edi_attachment_file` (unspecified how)
- User sends the move to SdI for a Public Administration partner
- IAP signs the attachment and sends it back to Odoo
- Odoo raises an error because it tries to use dictionary features on a binary field
- Odoo does not save the transaction ID, and if the user tries to resend the move, a Duplicate Error occurs from the SdI side.

Ticket [link](https://www.odoo.com/odoo/project.task/5954645)
opw-5954645

Forward-Port-Of: odoo/odoo#253459
Forward-Port-Of: odoo/odoo#252966

Steps to reproduce:
--------------------------------
1. Install Subscription module
2. Create a new subscription quotation and confirm it
3. Generate an invoice for the subscription
4. Attempt to cancel the subscription
   * A ValidationError is correctly raised
5. Close the subscription by selecting any close (churn) reason
6. Attempt to cancel the same closed subscription again

Observation:
--------------------------------
The subscription is successfully cancelled even though it already has invoices

Issue:
--------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/sale_subscription/models/sale_order.py#L741-L742 The cancellation logic does not check whether a subscription is already churned and still has active invoices

Solution:
--------------------------------
Added an additional condition to prevent cancelling churned subscriptions that still have active invoices

opw-5479719

Forward-Port-Of: odoo/enterprise#109755
Forward-Port-Of: odoo/enterprise#106596

Steps to Reproduce:
1. Open the website module.
2. Open the media upload dialog to upload an image by either
double-clicking the logo or replacing the existing image.
3. Upload a large file.
4. Abort the upload before it finishes by clicking the 'Discard'
button in the media dialog box.
After performing these steps, a traceback is observed.

Before this commit:
- Image upload failures would throw uncaught exceptions.
- These exceptions would interrupt the flow and result in a poor user
experience with no clear feedback.
- Even after clicking the discard button the image was still
getting uploaded.

After this commit:
- Uploads can be safely aborted when the media dialog is discarded.
- Ongoing XHR requests and RPC calls are properly cancelled.
- The upload loop stops immediately when an abort is triggered with
no traceback.
- Users get a predictable and clean exit instead of a broken state.
- Files are no longer uploaded after clicking Discard.

### task-4752497

Forward-Port-Of: odoo/odoo#250065
Forward-Port-Of: odoo/odoo#219081

When writing to a PoS config, it will automatically set an
`advanced_employee_ids` if none is set. But it will take any employee
that is part of `point_of_sale.group_pos_manager`. If the employee
selected is not part of the same company as the PoS config, and the
current user doesn't have HR employee access it will trigger an ir.rule
that block the user from opening the settings.

Steps to reproduce:
-------------------
* Create a new company
* Create a new user that only have access to this company and no HR
  access
* Create a PoS in the new company
* Login as the new user
* Try to open the settings
> Observation: You will get an access error because the employee set in
  `advanced_employee_ids` is from the other company

Why the fix:
------------
We make sure that when automatically setting the advanced_employee_ids
we filter out the ones that are not from the correct company. If no
employee exist that satisfies the requirements, we take a user from the
`group_pos_manager` and create an employee for him.

opw-5885417

Forward-Port-Of: odoo/odoo#253687
Forward-Port-Of: odoo/odoo#252402

[FIX] planning_field_service: fix follow-up (round 4)
This commit continues to fix the various issues found due to the
refactoring of Field Service feature to integrate it into planning
instead of being an extension of project.

This commit will:
- fix 'Print' action and ticket to intervention portal access
- always display in range mode for planned dates in planning.slot view
- update billable and non-billable filters to take into account
  `under_warranty` field
- review search view of planning.slot, some filters have been renamed
  and moved.
- use employees instead of resources in portal list (no need to display
  the material resource in the portal views in other words)
- add "Send mail", "Send SMS", "Send Report" and "Add/Remove followers" buttons
  in cog menu of list and kanban views of planning.slot model.
- remove helper in ticket button since it does not bring useful
  information.
- add ticket description on related shift, when the user plans an
  intervention from a helpdesk ticket, the new shift created from that
  action, will have the description of the related ticket inside Note
  field (name field)
- fix display_name, to avoid displaying the field used in the group by
  in the display name since it is a bit redundant
- take into account worksheet set in product as default
- fix some labels, visibility conditions, dates format, group_expand
- add default company of the slot when the user creates a resource from
  the form view of planning.slot model
- show customer preview stat button once the intervention is completed
  and a report is available for that intervention
- update tooltip for employee product to bring more context to explain
  how that new field works.
- make sure the SOL for timesheet is not generated when we complete an
  intervention if the project linked is non billable
- add icon on stat button of timesheet
- make sure the user can only create service product in product field in employee
- show "X Products" button to non sale user in the form view of
  planning.slot
- make project billable and timesheetable by default when the user wants
  to create a new project from the project_id field inside the form view
  of planning.slot model
- hide schedule stat button in the form view of project.task if the task
  is a template or linked to a project template
- update visibility condition of sign in in calendar, to make visible
  for planning manager when the slot is published even if the shift is
  not assigned to that user and the slot is in the past.

task-6009593

**Problem:**
the default account suggested for landed cost (with 
real time category) are not the good ones.

**Steps to reproduce:**
- create a storable product with perpetual average category
- create a landed cost (a service product with 'is a 
landed cost' checked in the purchase tab)
- create a category for the landed cost with perpetual valuation
- confirm a purchase order for 10 quantity of the product with a 
unit price of 10
- validate the receipt
- confirm quotation for 3 of the product, validate the delivery and 
confirm the invoice
- create a bill for the purchase order
- on the invoice lines, unhide the product column
- add an invoice line with the landed cost product, for a quantity 
of 1 and a price of 10
- confirm the bill
- click on create landed cost 
- select the receipt in the transfers field
- validate
- click on the journal entry on the landed cost form

**Current behavior:**
On the bill, for the landed cost : 
- stock valuation is debited of 10
- account payable is credited of 10 (which makes the total 
credit 110 for account payable)

On the journal entry linked to the landed cost: 
- stock valuation is debited of 7 
- stock valuation is credited of 7

So in total there is a debit of 10 in stock valuation and 
a credit of 10 in account payable.
Which does not reflect that part of the products are out 
of stock. 

**Expected behavior:**
If the expense account was used, both on the bill and on 
the landed cost, (which is already the case for landed cost
with periodic category) the account move lines would be: 

On the bill : 
- Expense is debited of 10
- account payable is credited of 10 (which makes the total 
credit 110 for account payable)

On the journal entry linked to the landed cost: 
- stock valuation is debited of 7 
- Expense is credited of 7

So in the total there is : 
- a credit of 10 in account payable
- a debit of 7 in stock valuation
- a debit of 3 in expense

This is what we want, because the debit of 7 in stock valuation 
reflect that we only increase the valuation by 7 because only 7 
products are still in stock. 
The debit of 3 in expenses compensate for the cogs. Indeed 
when we invoiced the SO, the cogs where of 30 but, after the landed
cost, valuation wise, the products actually exited the stock with a 
value of 33 total (11 each).

**Cause of the issue:**
For the bill: 
when you create the new account move line and enter the product, 
_compute_account_id is called to compute the default account 
for the line. 
In the stock override, _eligible_for_stock_account is called on the line
https://github.com/odoo/odoo/blob/3542c542eac5b204e69a8dd6ae1907cfcef60af3/addons/stock_account/models/account_move_line.py#L18-L19
Because of the stock_landed_costs override, the return value is true
https://github.com/odoo/odoo/blob/3542c542eac5b204e69a8dd6ae1907cfcef60af3/addons/stock_landed_costs/models/account_move.py#L78-L82
So the account is changed to stock valuation
https://github.com/odoo/odoo/blob/3542c542eac5b204e69a8dd6ae1907cfcef60af3/addons/stock_account/models/account_move_line.py#L23-L24

For the landed cost: 
- if we create it by selecting 'create landed cost' on the bill : 
the account id is set in button_create_landed_cost
https://github.com/odoo/odoo/blob/3542c542eac5b204e69a8dd6ae1907cfcef60af3/addons/stock_landed_costs/models/account_move.py#L34
-if we create the landed cost, from adjustment/landed cost and 
selecting new : the expense account is already selected


**fix:**
In both cases, the client can already manually set the 
accounts they want, the fix is about having the right 
default accounts. 

opw-5941753

Forward-Port-Of: odoo/odoo#253430
Forward-Port-Of: odoo/odoo#251766