## [IMP] databases: SSO smooth connection and setup

The aim of this commit is to allow databases_user to be directly connected to
any remote SaaS database to which they have access.
When they click the "connect" button, they will bypass the login screen and be
authenticated automatically.

To achieve this, when a user tries to connect to an accessible SaaS database, we
quickly write their `oauth_uid` to that remote database right before the
connection is initiated.

Before this commit:
A user that was created in the remote db using the create user feature from the
databases module wouldn't get automatically authenticated through the Odoo
OAuth SSO feature.

After this commit:
Users attempting to connect to a SaaS database will be directly connected if the
settings was activated.

task-id: 6071808

## TODO:
- [x] check if we always have oauth_uid for saas db
- [x] think about making the oauth module autoinstall (make a bridge module? or overkill?)
    - We can avoid that and have everything work in place directly, avoiding an inheritance nightmare at installation time. 
- [x] handle cases where it isn't there on both the remote db and the managing one
- [x] write some tests to ensure the code is free from traceback
- [x] add a feature allowing to:
    - [x] add it to all server on which the user has access
    - [x] add it to a specific server (may require the db list view on `res.users`
    - [x] remove the previous and do everything when the user click on "connect"
- [x] would be better to put the code in a new module with auto install => people get auto-install + no "hacky" code.
    - The "hacky" code is not so hacky and with that we can directly advertise the installation of `auth_oauth` in an action
    - [x] add a config in the settings

Issue:
Sending Debit Notes to a tax authority can cause the following error: "ValueError: The following child node is not defined in the template: DebitNote/cbc:BuyerReference"

Steps to reproduce on any database with DIAN and Colombian localization:

  1. Create a new "Sales" type journal. Then, check the checkbox “Nota de Debito”.
  2. Find a res.partner with a ref field, or add a ref field to any partner.
  3. Make an invoice using the partner found in step 2. Ensure it uses a tax. Confirm it.
  4. Send that invoice to DIAN.
  5. Create a Debit Note for that invoice. Use the journal created in step 1.
  6. Add a product, price, and tax to the debit note. Confirm it.
  7. Send the debit note to DIAN.
  
Explanation:
The `_add_invoice_header_nodes` method on the AccountEdiXmlUbl_21 model adds a BuyerReference node unconditionally. (See account_edi_xml_ubl_21.py.) But the DebitNote XML template does not include a BuyerReference element (see ubl_21_debit_note.py). This caused a ValueError when assembling the XML for debit note documents.

Solution: The fix overrides this in the Colombian localization by clearing the BuyerReference value when the document type is "debit_note". That way, the node is omitted from the output.

opw-6181039

When we scan a gs1 barcode that has in his lot a special character and start with 10, odoo will not be able to retrieve it from the db.

**Steps to reproduce**

* In settings activate:
  - Lots & Serial Numbers
  - Units of Measure & Packagings
  - Storage Locations
  - Barcode Scanner : GS1 nomenclature
* Create a Product tracked by lot with
  - barcode: 00001234567895
* Add on hand quantity:
  - 100 kg in lot : 10002002303-4
  - 100 kg in lot : 11002002303-4
* Go to barcode>Operation>Internal Transfer>New
* Scan 02000012345678951010002002303-4#3100000100 meaning:
  - 02 following 14 characters are the product barcode
  - 10 following characters are the lot number
  - "#" separator
  - 3100: means the units are kilograms, 
  - 00100 means 100 units. 

-> if you check with the edit button the lot was not found (if you click on validate it will trigger an UserError for missing lot)

**Observation**

When scanning the GS1 barcode it will call onBarcodeSubmitted->onBarcodeScanned where we will execute processBarcode: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/components/main.js#L387 Where we will deconstruct the barcode into his component en retrieve from the db the relevant data: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/models/barcode_model.js#L709-L717

- First the barcode is parsed, identifiers are erased and each section is separated, the variable with our lot number only has the lot number in it, the identifier (10) is not included, BarcodeObject.forBarcode(bc) -> new BarcodeObject -> parser.parse_barcode: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/barcode_object.js#L14
- Check if the data is in the cache, if not, set it to retrieve after
- Retrieve missing data getMissingRecords : https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/lazy_barcode_cache.js#L349 From here we will get a call to get_specific_barcode_data for each element: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L176 In the case of the stock.lot since it has a symbol and it's not only digit it will skip the gs1 nomenclature domain converter (it will not become 'ilike' and stay with 'in'): https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L182-L197 We will do the search:
https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L205 during which we will retrieve specific query from the stock.lot module : https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/odoo/orm/models.py#L1408 Where, since it's a GS1 nomenclature, we will preprocess the agrs: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/models/stock_lot.py#L14 
-> Since our barcode start with a 10, it will erase it, which lead to a miss in the search.


It will also avoid further searches since we avoid multiple search on the same elements (added in missingBarcodeKeyCache in getMissingRecords). https://github.com/odoo/enterprise/blob/c6d18a7a92092ffdf96f4569a70e95bdc276441c/stock_barcode/static/src/lazy_barcode_cache.js#L294-L298

opw-6207120

## Current behavior:
In the Project's app, switch to Gantt chart's view, when changing the deadline of a single task by shrinking its right edge, the server throws `ValueError: max() iterable argument`` is empty when calling end_date = max(candidates.mapped(stop_date_field_name)).

## Steps to reproduce:
1. In version 19.0 and above, install Project app
2. Create a project and only 1 single task
3. Switch to Gantt chart view
4. Try changing the deadline of a task by dragging its right edge
5. Observe that extending the task's deadline by dragging to the right works fine, but shrinking the deadline by dragging to the left will cause server to throw RPC_ERROR: Odoo Server Error and ValueError: max() iterable argument is empty.

## Cause of the issue:
- A task with NO successors will cause candidates gathered via dependency_inverted_field_name to be empty.
- The empty candidates recordset then get called by max(candidates.mapped(stop_date_field_name)), which is the reason causing error message ValueError: max() iterable argument is empty.

opw-6283566

Issue
-----
When making an international delivery to a partner with different invoice and delivery addresses, we send the delivery address as the `Sold To` address as well.

Problematic case 1
-----
- Create a belgian company
- Setup UPS
- Create a French customer
	- Add a different french delivery address
- Create a product (with some weight)
- Create a SO (with UPS delivery) to the customer & confirm
- Validate the transfer

> Commercial invoice `Sold To` uses the delivery address

Solution for case 1
-----
Use the delivery address' `commercial_partner_id`. This leads to another issue in some edge cases...

Problematic case 2 (caused by case 1 fix)
-----
- Create a belgian company
- Setup UPS
- Create a French customer
	- Add a delivery address in Switzerland
- Create a product (with some weight)
- Create a SO (with UPS delivery) to the customer & confirm
- Validate the transfer

> UPS error `The Sold To party's country code must be the same as the Ship To party's country code with the exception of Canada and satellite countries.`

Solution for case 2
-----
Default back to delivery address for the `Sold To` field when countries don't match, as this is a limitation of the UPS API. Warn the user, either on the SO or the transfer itself (if no SO).

Warning looks like this (on SO):
<img width="1914" height="716" alt="image" src="https://github.com/user-attachments/assets/f7aa73c4-f24c-42da-8f3e-6a58765ef020" />

-----
Ticket:
opw-6200263

Forward-Port-Of: odoo/enterprise#120592
Forward-Port-Of: odoo/enterprise#118031

When setting an account to an account.bank.statement there is a step to automatically create a reconciliation rule/model if one does not exist already. To do so, we retrieve 5 account.bank.statement.lines and use them to define the reconciliation model config. A matching is done on the payment_ref of the account.bank.statement.lines by finding the longest common substring in the reference.

### Current Implementation
The current algorithm does so by first generating all the possible substrings for all the payment_ref before doing the intersection between these sets and returning the max if `len(substring) >=10`. This is reasonable when the payment_ref follows either a SEPA communication national standard like the Belgian one or the Creditor Reference standard (ISO 11649). For transactions with large, unstructured communication with more than 100 chars, the method `_get_common_substrings` quickly overfill the memory, sometimes raising a MemoryErorr, and takes a significant amount of time. That's because the nested function `_generate_all_substrings` generates n*(n+1)/2 substrings, with n being the lenght of a payment_ref, called `label` in `generate_all_substrings`.

### Proposed Fix
This commit introduces another algorithm to find the largest common substring. It starts by taking the two smallest labels to find their substrings intersection. We know that for an arbitrary collection of labels, the intersection of their substrings sets A ∩ B ∩...∩ Z is included in the intersection of any two substrings sets. The underlying assumption of the first step is that for an arbitrary collection of labels the intersection of the substrings sets of the two smallest labels will be the smallest intersection of any given pair of substrings sets. This won't hold true everytime and using a metric such as label similarity instead of shortest string might be better. But on average this should be good enough and it's easier to implement + it removes the need of preprocessing the labels to compute the similarity.

The point of the new nested function `common_substrings` is to discard common substrings as we build them. Using the current `generate_all_substsrings` on either the smallest label or both smallest
labels would still generate and store a lot of substrings, especially for large labels. By yielding the common substrings as we find them, the memory footprint is vastly reduced.

Lastly, the next substring in the common_substrings iterable is only checked against the remaining labels if it's longer than the current match. This speeds up the whole process

### speedup

In a customer database with some account.bank.statement.line with payment_ref > 500 chars, setting a specific account (code 4970) on transactions goes from MemoryError to < 1Mb memory consumption.

Because of the memory consumption it was not possible to gather timing value on the current version. 
Testing the new algorithm in a shell and using as labels the 5 longest payment_ref in the customer database
(831, 831, 1117, 1178, 1300 chars), averaging to 2000 chars once normalised, the average time to execute `_get_common_substrings` is 900 ms ± 10.3 ms.