Steps to produce:
---
- Install `mrp`.
- Go to Manufacturing > Products > Bills of Materials.
- Click Create, select a product.
- In the Product Variant field, type any value and click "Create".

Issue:
---
Using quick create on the Product Variant field does
not create a variant of the selected product template. Instead, it
creates a completely new, unrelated `product.template`. This is because
the `create()` method on `product.product` is overridden to call super()
with context `create_product_product=False`, which suppresses direct
variant creation and forces creation through `product.template` instead,
see [1].

**Why passing `default_product_tmpl_id` does not help:**
One might expect that passing `default_product_tmpl_id` in the field
context would cause the newly quick-created `product.product` to be
linked to the already-selected `product.template`. However, because of
the `create()` override above (introduced in [commit]), the variant
creation is always redirected to `product.template`, ignoring any
`default_product_tmpl_id` passed in context. It is therefore not possible
in any case to quick-create a `product.product` that is correctly and
directly linked to the currently selected `product.template`.

Fix:
---
Disable the "Create" and "Create and Edit" options. Since there is no
way to quick-create a `product.product` that is correctly linked to the
currently selected `product.template`, the user must create the variant
directly on the product template first.

[1]https://github.com/odoo/odoo/blob/f04d79d44873d0f1c35303a1a892f3a3a394ea17/addons/product/models/product_product.py#L364-L368

[commit]: https://github.com/odoo/odoo/commit/7389345696720255a9d3c72ca1d9c2f4e4ecd7b8

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

Forward-Port-Of: odoo/odoo#259776

Prior to this fix, the parser walked through message parts that should have been ignored.

Emails utilize the MIME mechanism (RFC 2045), where the structure of an email is defined by boundaries that delineate different parts. Each part contains its own Content-Type (RFC 2045) and an optional Content-Disposition (RFC 2183). The Content-Type header describes the body content so the receiving user agent can select the appropriate mechanism to present the data. The Content-Disposition header defines whether the content should be displayed inline (in Odoo, understand this has "add it in the body") or treated as an attachment (in Odoo, create an ir.attachment and attach it to this mail.message). See `_message_parse_extract_payload` in https://github.com/odoo/odoo/blob/9218d302b0fd56c1854d95d3756c0f5e9c9c8700/addons/mail/models/mail_thread.py#L1547-L1549


The Issue:
When an email has a `Content-Type: message/rfc822`, it contains the body of a previously sent EML as an attachment. This embedded message possesses its own internal boundaries and parts. These sub-parts should not be processed as part of the top-level email’s primary structure.

In the case of opw-5892642, the email contained two text/html parts: one in the main email and one within the message/rfc822 attachment. The parser incorrectly reached into the attachment, allowing the second text/html part to override the first, leading to significant data loss. This override occurred within the _message_parse_extract_payload function: https://github.com/odoo/odoo/blob/9218d302b0fd56c1854d95d3756c0f5e9c9c8700/addons/mail/models/mail_thread.py#L1615-L1618


The Fix:
The new implementation adopts the logic used in the CPython email library iterator (cpython/Lib/email/iterators.py), specifically the _structure function. The updated logic ensures the parser walks through the mail structure without descending into nested levels it should ignore, staying focused only on the relevant part.

RFC1341 - 7.3.1:
A Content-Type of "message/rfc822" indicates that  
the  body contains  an encapsulated message, 
with the syntax of an RFC 822 message.

opw-5892642

Issue
-----
When there is a packaged quant in stock, the `least package` removal strategy has unexpected behaviour.

Steps to reproduce
-----
- Enable packages
- Create a product AAA tracked by SN
	- product category removal strategy set to "Smallest number of packages"
- Create a reception for 5 units
	- Generate serials
	- Put last line in pack
- Confirm reception
- Create delivery for 2 units of AAA
	- Mark as Todo
	- Change the quants taken: instead of SN 5, take SN 3 (so take SN 3 & 4)
- Create a delivery for 3 units of AAA
	- Mark as Todo

> Quantity reserved is one, it only reserved SN 5

Cause
-----
The problem arises in `_run_least_packages_removal_strategy_astar`. Because there is an available quant inside a package, we continue past

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L675-L676

We end up at

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L724

The `generate_domain` function has a problem: if there sin't enough products inside packages to satisfy the demand, it searches for items not in packages to take from.

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L701-L705

This search is flawed, because it does not take into account the fact that the quant might already be reserved. So it expands the domain with an `AND` on quant ids that are not available.

This leads to `quants` in `_get_reserve_quantity` containing unavailable quants

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L866

This later gets "caught" in `available_quantity`

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L897

and the quants don't get reserved a second time thanks to

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L912-L914

but this also means the reservation is incomplete.

Note that calling `action_assign` a second time will correctly reserve the remaining quantities, as there is no package left to reserve in stock, so we do go in

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L675-L676

and avoid the faulty logic.

Solution
-----
Ideally, we would use the value of `available_quantity` in our search domain. However, the field is not stored

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L88-L91

Our options are:
- make the field stored (not stable)
- add a search function
- filter reserved quants out of `single_item_ids`

First option is not stable. Second option requires subqueries to compare `quantity` and `reserved_quantity`. Third option is the least bad one, with only a very situational performance loss.

-----
Ticket:
opw-5972350