### 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

#### [FIX] stock_barcode: restrict product scan pckging
> #### How to reproduce:
> - Create a product with a product packaging and set a barcode for this packaging;
> - In the Receipts operation type config, check the product mandatory scan;
> - Create and confirm a receipt for the created product;
> - Open the receipt in the Barcode app;
> - Scan the product's packaging => A notification asks you to scan the product first.
> 
> This behavior is not right, a packaging should be a valid scan too for product's mandatory scan.
> 
> [OPW-4062460](https://www.odoo.com/odoo/project/49/tasks/4062460?cids=1)

### [FIX] stock_barcode: GS1 packaging with lot
> #### Steps to reproduce:
> - In Inventory settings, choose GS1 as barcode nomenclature and activate packages;
> - Create a storable product tracked by lot;
> - Create a lot for this product (e.g.: 12345);
> - Create a second storable product tracked by lot;
> - Create a new lot with the same name (12345) and a packaging on the product page with the barcode number 10000000240489;
> - Go back to the barcode app and create a new delivery;
> - San the barcode 01100000002404891012345
>   => The line is added for the right product but the lot is missing.
> 
> #### What happens:
> When the GS1 barcode is parsed, we got a lot name and a packaging barcode, thus, we will search a lot for the scanned lot name.
> To avoid fetching the wrong lot in case multiple lots have the same name (but different product), we give a filter when the lot is scanned alongside a product.
> The issue here is we didn't scan a product but a packaging and we forgot to give the same filter in this case.
> 
> [OPW-3894500](https://www.odoo.com/odoo/project/49/tasks/3894500?cids=1)


### [FIX] stock_barcode_picking_batch: reserved lot
> Bug introduced by: https://github.com/odoo/enterprise/pull/63908
> 
> #### How to reproduce:
> - Create a product tracked by lot;
> - For this product, add some quantity in stock for at least two different lots;
> - Create a delivery for this product, with enough quantity to reserve at least two different lots;
> - Confirm it and add it into a batch;
> - Open this batch in the Barcode app;
> - You should have a button to display reserved lots on the product line, click on it, it will display the reserved lot AND select the first one;
> - Scan a reserved lot other than the first one => The first one will be replaced by the scannned lot even if there is already another line with this lot.
> 
> [OPW-4017945](https://www.odoo.com/odoo/project/49/tasks/4017945?cids=1)

Forward-Port-Of: odoo/enterprise#67267

Steps to reproduce
==================

- Open a product form
- Open Studio
- Remove the "Internal Notes" block from "General Information"
- Add a new field

=> The normalized view contains many operations, it should only contain one move and one insertion

Cause of the issue
==================

The normalization compares the original view with the view with all operations applied. To do this, it stringifies every node and then does a textual diff between the original and modified versions.

The issue in this case is that there are multiple ways to represent a diff.

In this example, we remove the first group

```xml
<form>
    <group/>
    <group/>
</form>
```

```xml
<xpath expr="/form/group" position="replace"/>
```

The before stringified view is represented as

```
/form/group
/form/group[@closed]
/form/group
/form/group[@closed]
```

The after stringified view is represented as

```
/form/group
/form/group[@closed]
```

There are two ways to represent this diff

```diff
- /form/group
- /form/group[@closed]
  /form/group
  /form/group[@closed]
```

```diff
  /form/group
- /form/group[@closed]
- /form/group
  /form/group[@closed]
```

In this case, we only want the first one, but the second one is generated.

Solution
========

We can assign an id to every node before performing the diff, this way, the nodes are uniquely represented.

The before stringified view will be represented as

```
/form#1/group#2
/form#1/group#2[@closed]
/form#1/group#3
/form#1/group#3[@closed]
```

The after stringified view is represented as

```
/form#1/group#3
/form#1/group#3[@closed]
```

The diff can now only be represented in one way

```diff
- /form#1/group#2
- /form#1/group#2[@closed]
  /form#1/group#3
  /form#1/group#3[@closed]
```

opw-3819667