_* = helpdesk_sale_timesheet, sale_timesheet_enterprise

This commit adapts the community changes that centralized the reinvoicing flow
of analytic lines and renamed the field `timesheet_invoice_id` to `reinvoice_move_id`

The main technical change concerns how analytic lines to reinvoice are retrieved

Previously, analytic lines were always searched per invoice line. This was
needed in some situations, because for subscription timesheets the valid date
range can depend on the related sale order of each invoice line.

With this change, the specific per-invoice-line logic is now only used when all
of the following are true:
* No explicit `timesheet_start_date` or `timesheet_end_date` is provided in
  the context
* The invoice is linked to at least one sale order that:
  * is a subscription order
  * contains products delivered through timesheets.

Only in this case do we compute date ranges from the related sale orders and
search analytic lines separately per invoice line.

In all other cases, the standard aggregated search from the parent
implementation is used, which avoids unnecessary processing and speeds up
reinvoicing flow.

task-5490517

See Also:
- https://github.com/odoo/odoo/pull/245216
- https://github.com/odoo/upgrade/pull/9366

Currently, an error occurs when selecting a date on a rental product. 

**Steps to Reproduce:**
 - Install the `website_sale_stock_renting` module.
 - Go to `Products` and create a product with the following `configuration`:
   - Enable `Track Inventory` and set `Quantity On Hand` greater than zero.
   - Disable `Sell when Out-of-Stock` under the `eCommerce tab`.
   - Under the `Sales tab`, set `Periodicity to Days`, and set the same time for `Pickup and Return`.
 - Go to `Website > Shop`.
 - Open the product, select the same date for both `Start Date and End Date`, and `click anywhere`.

`ValueError: min() iterable argument is empty`

**Cause:**
 - This error occurs because when the start and end dates are the same, the method returns a set 
   of dates from here [1]. Since there is only a single date, the loop is not executed and it returns 
   an empty list of availabilities [2], which then raises the error [3].
 - The error happens due to the removal of this condition [4] in this [recent commit].
 - The warning message is now handled here [5].

**Fix:**
 - This commit ensures that when a user selects a start date that is greater than or equal to the 
   end date, a UserError is raised and the proper warning message is displayed.

[1]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/sale_stock_renting/models/sale_order_line.py#L616

[2]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/website_sale_stock_renting/models/product_product.py#L77

[3]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/website_sale_stock_renting/models/website.py#L18-L22

[4]: https://github.com/odoo/enterprise/blob/66f144df6f2056212797547dfef5ed58232698cd/website_sale_renting/models/product_template.py#L175-L176

[5]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/website_sale_renting/static/src/interactions/daterange_picker.js#L213

[recent commit]: https://github.com/odoo/enterprise/commit/4afdc272e5a7fc4284bbd9f97283b8ec0aa28c34

sentry-7243018656

Forward-Port-Of: odoo/enterprise#106602

**Steps to reproduce:**
* Install the `stock_barcode`, `quality_control` modules.
* Go to *Inventory > Configuration > Settings* and enable **Packages**.
* Create a product with **By Lot** tracking enabled and set a barcode reference.
* Create a quality control point for this product with following configuration:
  * Operation: *Receipts*
  * Control per: *Quantity*
  * Control Frequency: *All*
  * Product: the previously created lot-tracked product.
* Create a receipt for this product with a quantity of 6 and `mark as todo`.
* Open the *Barcode* app and process the receipt.
* Scan the product barcode.
* Scan some quantity of the product with lot *LOT01* and put those units into a 
package(Put-In-Pack).
* Scan the remaining quantity with lot *LOT02* and put those units into a
 different package(Put-In-Pack).
* Click on **Quality Checks**.

**Observed behavior:**
* Only one quality check is created, even though the receipt contains two different
lots that should each generate a quality check.

**Cause:**
* In `_inverse_qty_done`, move lines are marked as *picked* when `qty_done` is
equal to quantity(Demand).
* During the `write` operation, quality checks are created only for move lines
that are not picked, which prevents creating a quality check for each lot.
* Relevant code: https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/quality_control/models/stock_move_line.py#L39 https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/stock_barcode/models/stock_move_line.py#L67-L71

**Fix:**
* Ensure that quality check points are generated correctly when validating
products through the Barcode app using the Put in Pack option.

---

opw-5405221

Forward-Port-Of: odoo/enterprise#105930
Forward-Port-Of: odoo/enterprise#102714

## Issue

When using the *Default GS1 Nomenclature*, it is possible to create multiple lot/serial numbers with a same name if the name matches a barcode rule pattern.

## Fix
The fix related to this commit is introduced by [this PR](https://github.com/odoo/odoo/pull/244427).

## Problematic flow
The problematic flow starts in the `StockLot._check_unique_lot` method when calling `self._read_group`. At that point, the domain is still correct: it contains the product_id and the (correct) name for the lot we try to create.

https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/addons/stock/models/stock_lot.py#L104-L111

In the `BaseModel._read_group` method, the query is defined by the `self._search` method. At that point, the domain is the same as in the previous step, so it is still correct.

https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/odoo/orm/models.py#L1902-L1904

Now the flow differs depending on whether the `stock_barcode` app is installed or not. If it is, the `stock_barcode/StockLot._search` method is called:

https://github.com/odoo/enterprise/blob/24fea3814b95144953fb809d10bf6a62906c06fd/stock_barcode/models/stock_lot.py#L11-L15

This is the method that calls the `BarcodeNomenclature._preprocess_gs1_search_args` which uses the `skip_preprocess_gs1` context flag:

https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L149-L151

**This flow makes the query returned by `self._search(domain)` erroneous, as the start of the name of the lot is removed further down the execution of the `preprocess_gs1_search_args` method.**

### If stock_barcode is not installed

The `self._search` method called in the BaseModel will not call `stock_barcode/StockLot._search`, but instead it calls `BaseModel._search`. This totally skips the problematic gs1 flow.

opw-5477003

Forward-Port-Of: odoo/enterprise#104720