### Steps to reproduce:

- In the settings Enable Multi-steps route
- Create a product FP with a BOM:
  - 1 component: 1 x COMP (tracked by SN)
  - 1 operation: "Register SN on COMP"
  - Add an instruction on your op:
    - type: "Register consumed component"
    - Product To Register: COMP
- Put 2 SN for COMP:
  - SN01 in Stock/Shelf1
  - SN02 in Stock/Shelf2
- Create and confirm an MO for 1 Unit of FP
> SN01 is reserved on the COMP raw move.
- Go to the shopfloor > "Register SN on COMP"
- Change the SN of the COMP from SN01 to SN02
#### > Go back to the stock MO the incorrect location was used

### Cause of the issue:

While the lot is correctly updated by the action here: https://github.com/odoo/enterprise/blob/e90cf74be3945d1f1256d398ca9c4b61bc35ed08/mrp_workorder/models/quality.py#L485-L507 The associated quant is not set and hence the move location_id, package, ... are not updated with it.

### Fix:

We take advantage of the `quant_id` dummy field of the `stock.move.line` to update the info to write thanks to the write override: https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L85 https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L399-L400 https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L911-L920

### Note:

Unfortunately, the Dialog opened when clicking on the the quality check from the shopfloor:
https://github.com/odoo/enterprise/blob/34ab94cdcc49f4ade66953874a03f2988b2b4317/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.js#L12 is not embedded in a form view so that the onchange: https://github.com/odoo/odoo/blob/366676cafdce00d55823c6daf41452b0c2373e4d/addons/stock/models/stock_move_line.py#L185-L192 is not triggered by our change of "lot_id".

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

Forward-Port-Of: odoo/odoo#185662

Currently, the relationship between stock.picking and purchase.order is done via a `related` non-store field that requires iterating all moves. This becomes problematic in a case like `_get_related_invoices` in the purchase_stock module because we need to get the purchase_id of a move, but to do that, we will have to go through the picking_id which will need to iterate all moves related to the same picking. When you have `_prefetch_ids` set on that move, this process becomes extremely slow and memory-expensive because the `purchase_id` field is not stored so it needs to compute the relationship for all moves in the expanded ids due to prefetching. 

Since there exists a Many2many relationship between stock pickings and purchase orders, it's possible to rely on a search query instead of the `mapped` call. Although this might miss some cache optimizations, it's still much more efficient in terms of memory. This is because this approach is not susceptible to prefetch_ids explosion. It's also worth noting that this function is only called on individual stock moves instead of batches as part of the anglo_saxon_accounting logic. That being said, we don't have to worry this much about cache optimization since the method is not batched to begin with.

Using this optimization, we get the following benchmarks. 

Benchmark:
| num stock.move (_prefetch_ids) | time before | no. queries before | time after | no. queries after|
|----|------|-----| ----- | ----- |
| 1000                   | timeout | N/A | ~ 85 seconds | 47897 |

opw-4096108





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

Forward-Port-Of: odoo/odoo#181822

Use cases: send an email to
 "Bike@Home" <info@bike.com>  (name containing @)
 "robert@exampl.com" <robert@example.com> (result of partner name_create)

When there is an email in the name field, emails are sent twice and
thus may be counted twice in various tooling, introduce unwanted or
extra recipients, ... This happens notably due to https://github.com/odoo/odoo/commit/795091c69d2bc40e3bd2b5ae29451ea3af07d908
combined to https://github.com/odoo/odoo/pull/74474 which improved support of multiemails and
formatted emails in various email input.

This notably leads to better formatted email computation on partner
that generates emails like '"email@example.com" <email@example.com>'
when email is used both as name and email. When sending emails to this
partner only a single email should be sent and counted.

A fix is been done to remove duplicates in that tool, making the returned
list unique. In this PR we allow to receive a pre-validated
list of emails that restricts emails found by 'extract_rfc2822'.
When going through classic flows, we already computed emails using
'email_split' and its subtools, hence we just need the encoding
check of 'extract_rfc2822'. Additional emails found by that tool
are ignored as we consider those are fake emails.

This PR contains tests and fixes related to that issue as well as multi
and formatted emails management.

Task-3704658

Forward-Port-Of: odoo/odoo#186798
Forward-Port-Of: odoo/odoo#185793

Issue:
Currently, if the related user is removed from an employee, the link with the res.partner is also removed. This makes it impossible to post expense reports, as a partner is required to do so.

To reproduce:
1. Create a new user.
2. Click ‘Create Employee’ in the user view
3. Go to the employee through the smart button
4. In the tab HR Settings, remove the related user
5. Create an expense report and try to post it (Expenses => New => Create Report => Submit to Manager => Approve => Post Journal Entries)
6. An error message about missing vendor (res.partner) appears

Cause:
The field work_contact_id keeps the link between hr.employee and res.partner, and is updated in the function _sync_user. Since work_contact_id=user.partner_id.id, when the user is removed from the hr.employee, work_contact_id is also removed.

Fix:
The link between hr.employee and res.partner should be kept until the user is assigned to another employee. In this case, the partner associated to the user should also be associated with the second employee, and no longer to the first employee.

To do so, _sync_user assigns _origin.user_partner_id to work_contact_id if no user is passed (in case the user is removed). A helper function is called when creating or writing an employee, to unlink the partner and the previous employee in case the user is assigned to another employee.

task-4049996


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

Forward-Port-Of: odoo/odoo#175478