To reproduce:
=============
- Create a 24-hour calendar representing a company without breaks.
- Create an employee who will be working a night shift 21:30 to 6:00
- Create an open shift from 21:30 to 6:00.
- as the company doesn't have breaks the shift will have 8 hours and 30 minutes of allocated hours. Set the allocated hours to 8 hours
- click auto-plan -> the employee is assigned to the shift but the allocated hours are changed
    to 7 hours and 32 minutes.

Problem:
========
- when setting the allocated hours to 8 hours, the allocated percentage changed to 94%.
- after auto-planning, and setting the resource to the shift, the allocated hours are recomputed based on the allocated percentage and the working hours of the resource which is 8 * 0.94 = 7.52 hours.

Solution:
=========
after finding the resource to assign to the shift, we should recomputed the allocated percentage based on the working calendar of the resource and the allocated hours set on the shift.

opw-3874283

#### [FIX] account,sale: credit_to_invoice in multi-company
Currently the credit_to_invoice includes sales orders
from all allowed companies.
But it should only include sales orders from the active company.
(Since a single sales order belongs to only 1 company)

#### [FIX] account: flush in _credit_debit_get of model res.partner
Function _credit_debit_get uses a raw SQL query,
but does not flush the used tables to the DB before.

Without this commit some of the tests in the following commits of this PR will fail
(since some of the invoice lines are not flushed yet).

#### [FIX] account,sale: credit limit in multi-currency setup
The partner credit limit (warning) may not be computed correctly in a
multi-currency setup.

Note that the partner credit is always in company currency.

1) Consider a draft invoice. To determine the warning amount
    the current amount in document currency (not company currency)
    is added to the current partner credit (roughly speaking).
2) To compute the credits from sales orders of the partner
    (credit_to_invoice) we just add the amount_to_invoice
    from each sales order of the partner.
    But this field is in the currency of the order
    and thus may be different from the company currency.

To fix these issues currency conversions were added for both cases.

#### [FIX] account,sale: credit limit warning
Currently the amount of the partner credit warning
on invoices is not computed correctly in some cases.
1) There are Sales Order credits
    and we create an invoice independent of any of SO
2) We create an invoice from a Sales Order with
    an amount greater than the Sales Order.

For (1) the problem is that we substract the current
amount of the invoice from the sales order credits
(since we need to do this in the sales order to invoice flow)
But in case the invoice does not come from a sales order
this is wrong.

For (2) the problem is that the `amount_to_invoice` of a
Sales Order may be negative. This can happen if we invoice
more than the sales order amount.
E.g. we can end up with one invoiced order with -100 and
one uninvoiced order of 100. In the sum this would leave us
with "nothing to invoice" (100 + -100 = 0).

Reproduce (1):
All monetary values here are in company currency.
- Ensure that the partner credit is 0:
  i.e. remove all Sales Orders and Invoices.
- Activate 'Sales Credit Limit' in the settings
  and set the 'Default Credit Limit' to 100
- Create a new customer; here 'Test'
- Create a Sales Order for customer of 200
  and deliver it
- The total partner credit is now 200
- Create an Invoice (not from the Sales Order)
  for customer 'Test' (without any lines at first).
- There should be a warning that the total amount
  due is 200 (since it exceeds the limit of 100).
- Add a line of 200 to the Invoice
  (any value ≤ 200 will do).
- The total amount due in the warning is still 200
  but it should be 400 (200 + 200)
- Change the line to 800 (any value > 200 will do)
- The total amount due in the warning is now 800
  but it should be 1000 (200 + 800)

Reproduce (2):
All monetary values here are in company currency.
- Ensure that the partner credit is 0:
  i.e. remove all Sales Orders and Invoices.
- Activate 'Sales Credit Limit' in the settings
  and set the 'Default Credit Limit' to 100
- Create a new customer; here 'Test'
- Create 2 Sales Orders for customer of 200 each
  and deliver it
- The total partner credit is now 400
- Create an Invoice from exactly one of the Sales Orders
  (full amount or downpayment does not matter here)
- There should be a warning that the total amount
  due is 400 (since it exceeds the limit of 100).
- Modify the invoice (any line from the sales order)
  s.t. it has a total of 400
- Confirm the invoice
- The amount_to_invoice of the Sales Order is now -200.
  The sum of the amount_to_invoice of the Sales Orders is 0.
- Create a new invoice without any lines.
- There is a warning that the total amount
  due is 400 (= 200 + -200 + 400 ; SO + SO + invoice).
  But it should be 600 since the "overinvoiced" SO
  should just be counted with amount_to_invoice 0.

Forward-Port-Of: odoo/odoo#164921
Forward-Port-Of: odoo/odoo#162770

The date_deadline propagation would update the sale records multiple times depending on some configuration (check example below). This happens because 'already_propagate_ids' is copied at the beginning of _set_date_deadline (set | set = new set). So, when a child move propagates to multiple other moves, it is not known by the parent move, which will redo the propagation.

To prevent this, we always keep the same reference for 'already_propagate_ids' (context: 'date_deadline_propagate_ids'). This means that a parent and child move share the exact same Set, and when the child move updates the Set, it also updates the parent Set. So when a child move propagates, the parent will know which moves have been done.
   MOVES LINKAGE
```
       Move B
      /   |   \
  Move A  |  Move D
      \   |   /
       Move C
```
PROPAGATION GRAPHS:
```
  BEFORE    |  AFTER
------------+--------
    A       |    A
  /   \     |    |
  C   B     |    B
 / \ / \    |    |
 B D C D    |    C
 | | | |    |    |
 D B D C    |    D
------------+--------
    11      |    4     NUMBER OF CALLS
```
OPW-3904178

![image](https://github.com/odoo/odoo/assets/29302288/8329d051-5927-4fec-b85d-3994f93d8cc0)


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

Forward-Port-Of: odoo/odoo#164734

Commit [1] added the support to also consider invisible dropped snippets when checking if the snippets in the right panel are droppable. In order for this status to be properly updated when showing and hiding invisible elements, the `reload_snippet_dropzones` event is now triggered in each call to `toggleTargetVisibility`.

However, this function is called a lot of times when doing different operations (e.g. drag and dropping (in `buildSnippet` and `cleanForSave` functions), removing a snippet, showing/hiding an invisible element), which means that `_disableUndroppableSnippets` is also called each time.

This slowed down the editor a lot:
- Drop a "Text-Image" snippet and click on it to activate it. 
=> It takes a bit long for the "Undo" arrow and the overlay to appear.
- Drag and drop one of the snippet columns.
=> It takes a while for it to be dropped and for the dropzones to disappear, while it should be instant.

It also made some tours having steps that drop snippets fail when launched in the browser console (e.g. `carousel_content_removal`). This happens because the "drop" step takes too long to complete, making the next one fail.

Also, this made the call to `_disableUndroppableSnippets` redundant in certain cases. For example, when removing a snippet: in `removeSnippet` there is a call to `toggleTargetVisibility` which will therefore call this function. At the end, it triggers the `snippet_removed` event which will call `_onSnippetRemoved` which also calls this function.

This commit therefore fixes these issues by removing the trigger from `toggleTargetVisibility` and by calling `_disableUndroppableSnippets` directly when showing/hiding invisible elements, so only when necessary.

[1]: https://github.com/odoo/odoo/commit/922b4ba13d679a237bcc43d7296ff402beacb022

task-3902277

Forward-Port-Of: odoo/odoo#164826
Forward-Port-Of: odoo/odoo#164159