### Issue:

The way that the `product_packaging_qty` field of the SOL model is defined and used can introduce an error on the qty of the SOL whose as high as half of the uom_rounding (seen as a percentage) of the qty_per_package 
E.G. with an uom_rounding of 0.01 you can introduce an error on the qty of the SOL that is up to 0.5% of the qty per package.

### Steps to reproduce the issue:

- Enable "Product Packagings" on products in the settings
- Create a storable product with a packaging containing 999 units
- Create a SO with a SOL for 1004 units of that product
- Add your packaging on the SOL

#### > the quantity went from 1004 to 1008.99 (error of 5 units that is 0.5%)

### Cause of the issue:

Rounding a float number can introduce an error of up to 0.5 the rounding precision e.g. 0.005 rounds up to 0.01 with rounding precision 0.01 which is is an error of half of its rounding precision.

The `product_uom_qty` of an SOL is computed by making the product of the `product_packaging_qty` with the `qty_per_packaging`: https://github.com/odoo/odoo/blob/0ffe4cbb5a112b3885f3b624872180bf7bc31891/addons/sale/models/sale_order_line.py#L424-L425 
As such, the `product_packaging_qty` is a ratio meant to be re-multiplied with product uom quantities. However, the `product_packaging_qty` is computed with the rounding precision of the `product_uom`:
https://github.com/odoo/odoo/blob/0ffe4cbb5a112b3885f3b624872180bf7bc31891/addons/product/models/product_packaging.py#L80 
Therefore the `product_packaging_qty` can carry an error as high as  half of the `uom_rounding`, that is, most often up to 0.5%. This introduce an error on the `product_uom_qty` that can therefore be as high as 0.5% of the `qty_per_packaging`.

### Fix:

Since each of the qty appearing in the quotients and products are rounded, it is impossible to avoid completely any rounding issue but since the `product_packaging_qty` is a ratio that is meant to be remultiplied by a product uom quantity its precision should as high as possible to not introduce any percentage deviation on the quantity.

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

### Steps to reproduce:

- Create 2 storable product
- Update the on hand quantity to 100 only for the first one
- Create an confirm an SO 75 units of each
- Set the done qty to 50 on both moves and create a backorder
- Print delivery slip for the original picking
#### > The Ordered quantity is wrong on the product with no stock on hand (50 instead of 75).

### Cause of the issue:

If there's no on hand qty the backorder move will not be associated to any `move_line` so that the `qty_ordered` will not be updated by these lines:
https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L785-L791 Furthermore, since they are not cancelled, they are filtered out here and hence do not update the `qty_ordered` by these lines either: https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L813-L816 https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L831

### Fix:

We modify the filter meant for empty move lines so that moves that are not confirmed and are not associated to any `move_line` contribute to the `qty_ordered` via these:
https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L831 However, since we do not want a move that is fully backordered to appear on the delivery slip we need to filter out all the line keys that will be created, because they pass our new filtering condition (but didn't pass the old one), here:
https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L819-L821

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

Forward-Port-Of: odoo/odoo#176196
Forward-Port-Of: odoo/odoo#175113

### Issue:

Changing the reservation method of a picking type on a large DB might result in a memory error invalidating the requested change.

### Cause of the issue:

The dependency `picking_type_id.reservation_method` was introduced on the `_compute_reservation_date` method of stock moves by commit c4023d7. This dependency was introduced to remove the reservation date on all moves whose picking type reservation method is no more "date". Because of this new dependency, if one change the `reservation_method` of a picking type say manufacturing, it will fetch and "recompute" the `reservation_date` of all stock.moves whose picking type is manufacting. The ORM will handle these records 1000 by 1000 but if you happen to have a million records of that picking type (which is the case of the customer) all of these records will be added to the cache during the `_fetch_query`. This will lead to a Memory error since the cache is not cleared after a certain amount of computed records during the `_compute_reservation_date`.

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

Forward-Port-Of: odoo/odoo#175873

### Steps to reproduce:
	- Install eCommerce module
	- Go to Website > Cart
	- Click on Edit > Customize > Extra Info
	- Go to Website settings and Check 'Extra Step During Checkout'

### Current behavior before PR:
The 'Extra Step During checkout' setting is not synchronized when turning on and off from website editor or from website settings. This actually leads sometimes that you might turn it on from website settings and it won't be visible in the checkout process. This is happening because in the 'res.config.settings' we are dealing with 'ir.ui.view' that is not linked to any website but in the website editor we are dealing with 'ir.ui.view' that is linked to the website you are editing.
https://github.com/odoo/odoo/blob/17.0/addons/website_sale/models/res_config_settings.py#L68 https://github.com/odoo/odoo/blob/17.0/addons/website_sale/models/website.py#L588

### Desired behavior after PR is merged:
When turning on/off the setting from the website settings now we are dealing with the 'ir.ui.view' that is linked to a website. So the setting is now website dependant.

opw-3992571

Forward-Port-Of: odoo/odoo#175929
Forward-Port-Of: odoo/odoo#170639

When importing a sale in PoS and doing a downpayment there was only one downpayment line created. And because of this the taxes where not always correct. If you do a 100% downpayment you would end up with negative untaxed amount on the invoice.

Steps to reproduce:
-------------------
* Create 2 taxes, A and B with 5% and 10%
* Create 2 products, A and B. Assign the 2 taxes to the products
* Create a sale order with the 2 products
* Open the sale order in PoS and make a downpayment for it
> Observation: There is only one downpayment line when it should have 2.

Why the fix:
------------
If you do the same flow in the sales app, you get 2 downpayment lines. We do this to allign the behavior in sales and PoS. For each unique tax combination we compute what part of the total downpayment should be assigned to it. Then we make sure that the taxes are assigned to the line and that the line has the right value.

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

Forward-Port-Of: odoo/odoo#174358
Forward-Port-Of: odoo/odoo#174076

Current behaviour:
---
When trying to make a xmlrpc call to search_read a crm lead that has a property, we get a traceback.

Steps to reproduce:
---
1. Install CRM
2. Go to the Pipeline
3. Open any lead
4. Click on Actions > Add properties
5. Input anything as value, then save
6. Make a xmlrpc call to retrieve leads (see below)
7. Traceback

`models.execute_kw(db, uid, password, 'crm.lead', 'search_read', [])`

Cause of the issue:
---
Feature introduction: https://github.com/odoo/odoo/commit/87307a9010c6c872fe6c746d5ece378ad90d038f 
Change from `None` to `False`: https://github.com/odoo/odoo/commit/608bffff59c9444f59a282dbdc43c207704223cc 
Issue caused by: https://github.com/odoo/odoo/commit/da48700b59da49cdc810eac31a8617fcaa0dc2a8 
(Due to the modification of `convert_to_read_multi`)

When adding `PropertiesDefinition` to an existing record, it doesn't go through 
`_add_default_values` again, thus making `None` not being replaced by `False`.
https://github.com/odoo/odoo/blob/cd9c69bd7d9b21e6220a49f88f22160de33c5e06/odoo/fields.py#L3616

opw-3940841

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

Forward-Port-Of: odoo/odoo#172689

When scrapping a kit, it leads to incorrect behaviours

**Case 01:**
1. Create a storable kit with one storable component
2. Validate a scrap order with that kit
3. Open the product moves

Error: we moved the kit instead of its component

We first create a draft SM with its SML:
https://github.com/odoo/odoo/blob/72c4a2352c1184f5e8c1f238d29eb94e37d01115/addons/stock/models/stock_scrap.py#L145
https://github.com/odoo/odoo/blob/72c4a2352c1184f5e8c1f238d29eb94e37d01115/addons/stock/models/stock_scrap.py#L112

During the SML creation, we check if we should recompute the state
of the SM:
https://github.com/odoo/odoo/blob/dc0917d2a55a12e5c30d413a46e2c16190fd8a08/addons/stock/models/stock_move_line.py#L344-L355
`reservation` is `True`, the SML has a quantity -> we recompute the
state of the SM -> it is now assigned
Back to the scrap, we now `_action_done` the kit SM
https://github.com/odoo/odoo/blob/72c4a2352c1184f5e8c1f238d29eb94e37d01115/addons/stock/models/stock_scrap.py#L147
which leads to
https://github.com/odoo/odoo/blob/6ed0d0ca2f90fef8cd020380b194498a9363267c/addons/stock/models/stock_move.py#L1827-L1830
Here is the problem: the SM has a demand, its state is not draft
-> we don't confirm it
-> we don't explode it
Hence the error. This is the reason why the commit stops providing
the scrap SM with an initial demand. That way, we will explode the
SM and everything will work as expected

**Case 02:**
1. Create a consumable kit with one storable component
2. Validate a scrap order with that kit

Error: a server error is raised "Missing record [...]"

This time, `reservation` is `False` (the diff comes from the kit
type, consu vs stor, c.f. `_should_bypass_reservation`). Therefore,
we explode it. Since we are in scrap mode, we generate SM with a
zero demand:
https://github.com/odoo/odoo/blob/68f981d2a690addf0b70ddab498b556986752e49/addons/mrp/models/stock_move.py#L464-L466
https://github.com/odoo/odoo/blob/68f981d2a690addf0b70ddab498b556986752e49/addons/mrp/models/stock_move.py#L527
Back to `_action_done`, we create the extra moves if needed:
https://github.com/odoo/odoo/blob/6ed0d0ca2f90fef8cd020380b194498a9363267c/addons/stock/models/stock_move.py#L1847-L1853
Here, our component SM has a done qty greater than its demand
(reminder: it demand is zero), so we will create the extra move,
confirm it and merge it with the initial one:
https://github.com/odoo/odoo/blob/6ed0d0ca2f90fef8cd020380b194498a9363267c/addons/stock/models/stock_move.py#L1799-L1802
Buuuuut... Step 2 in the use case, we validate the scrap order.
Since we don't have such product on hand, we trigger a wizard with
some default values:
https://github.com/odoo/odoo/blob/72c4a2352c1184f5e8c1f238d29eb94e37d01115/addons/stock/models/stock_scrap.py#L204-L219
And... Now you see where I'm going: when we create the extra move,
we still have these default values in the context -> the extra move
has a demand and(!) a done qty to 1. We merge it with the initial
move: we are now scrapping a component with a demand equal to one
and a done qty equal to 2. It will later lead to other
inconsistencies (among them, the server error raised)

opw-4090951

Forward-Port-Of: odoo/odoo#176186