When validating the payment CFDI in multicurrency scenario (invoice in USD, payment in MXN), we should provide the official convertion rate in the equivalenciaDR xml attribute. However, this is not always possible due to rounding: PACs with lower error tolerance (Quadrum) will not validate the payment

Steps to reproduce:
- With an MX company setup
- Set the following rates for USD
  - Date 1: 0.049905678268
  - Date 2: 0.049073733284
- Create an invoice in date1 of 6368.40 USD (5490.00 with 16% tax)
- Register a full payment in date 2 in company currency (129772.07 MXN) Issue: Payment CFDI will not validate when using Quadrum PAC with error

```
Code : CRP20268
Message : El campo BaseP que corresponde a Traslado, no es igual a la suma de los
importes de las bases registrados en los documentos relacionados donde el impuesto del
documento relacionado sea igual al campo ImpuestoP de este elemento y la TasaOCuotaDR
del documento relacionado sea igual al campo TasaOCuotaP de este elemento.
```

This occurs because when computing cfdi values we take the invoice (rounded) amounts and recompute the amount in mxn using the official currency rate. While doing so, due to rounding, we accumulate imprecision, the final computation might be off by a cent or two and PACs with a lower error tolerance (Quadrum) will not be able to validate the cfdi.

A solution is to internally use the computed rate, while we provide the official currency rate in the xml

opw-4357985

Forward-Port-Of: odoo/enterprise#76333

An error occurs when the system tries to access single values from multiple records at [1].

Link [1]: https://github.com/odoo/enterprise/blob/2e1af04e36fcbdcd11e3a7e2994673b2c4a5cf85/social_youtube/models/res_config_settings.py#L19

Traceback On Sentry:

```
ValueError: Expected singleton: res.config.settings(105, 106)
  File "odoo/http.py", line 2366, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1894, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1957, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 137, in retrying
    result = func()
  File "odoo/http.py", line 1924, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2171, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 727, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 35, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 517, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "odoo/models.py", line 6090, in search_read
    return records._read_format(fnames=fields, **read_kwargs)
  File "odoo/models.py", line 4032, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
  File "odoo/models.py", line 6999, in __getitem__
    return self._fields[key].__get__(self)
  File "odoo/fields.py", line 1291, in __get__
    self.compute_value(recs)
  File "odoo/fields.py", line 1473, in compute_value
    records._compute_field_value(self)
  File "odoo/models.py", line 5238, in _compute_field_value
    fields.determine(field.compute, self)
  File "odoo/fields.py", line 110, in determine
    return needle(*args)
  File "home/odoo/src/enterprise/18.0/social_youtube/models/res_config_settings.py", line 19, in _compute_youtube_oauth_client_id
    if self.env.user.has_group('social.group_social_manager') and self.youtube_use_own_account:
  File "odoo/fields.py", line 1232, in __get__
    record.ensure_one()
  File "odoo/models.py", line 6212, in ensure_one
    raise ValueError("Expected singleton: %s" % self)

```

To resolve this issue, Use an iteration(for loop) to iterate records one by one.

Sentry-6200420369

Forward-Port-Of: odoo/enterprise#76588

The reconciliation of move lines creates a cash basis (caba) move under some conditions. This can i.e. happen for the PoS move during the closing of a session.

But the PoS move does not use the transition account of any used caba taxes but the "real" account directly (see commit a011dcc0bdbe892b0a505a6a4169c5168bd018f6). So there is no need for a caba move.
Further an exchange difference move for the tax amount may be created. The issue is that the tax amounts from the cash basis are not being matched correctly with the tax amounts from the PoS move (since we only look for the transition account on the PoS move).

Reproduce on runbot for l10n_mx
1. Install l10n_mx
2. Set the 'IVA 16% VENTAS' tax as Customer Taxes on a product. Set the Sales Price to 100.
3. Create a payment method and journal for the PoS 
    * Payment method: Cash on journal CSH1
    * Journal: POS
5. Create a PoS using the payment method and journal from the previous step.
6. Start a PoS session
7. Sell the product from step 2 via the Cash payment method.
8. Close the Session
9. The following journal entries will be created: (All the tax lines use the same tax account; the "final" and not the caba transition account) 
```
* 1 entry in the POS journal (order)
       base:       | - 100.0 $
       tax:        | -  16.0 $
       receivable: | + 116.0 $
     * 1 entry in the CSH1 journal (cash / payment)
       cash:       | + 116.0 $
       receivable: | - 116.0 $
     * 1 entry in the CBMX journal (caba)
       base:       | - 100.0 $
       base:       | + 100.0 $
       tax:        | -  16.0 $
       tax:        | +  16.0 $
     * 1 entry in the EXCH journal (exchange difference)
       for the cash basis rounding difference
       tax:        | -  16.0 $
       tax:        | +  16.0 $
```

This commit fixes the issue by just skipping the creation of caba moves during the reconciliation of the PoS move lines. Further we make sure no exchange difference entry is created for the (not even created) cash basis entries.

opw-4355124

Forward-Port-Of: odoo/odoo#193375
Forward-Port-Of: odoo/odoo#193195

Minimal Configuration:
- Create an account (49999 Great Account) that has a default tax (15%)
- Settings > Accounting: define "Separate discount accounts on invoices" > Customer invoices with an account (e.g. 443000 Cash Discount Loss)

Steps to reproduce:
- Create an invoice with an invoice line that has "Great Account", a discount (10%) and a price (100) and a tax (15%)
- Confirm -> amount = 108.9
- Duplicate the invoice (in the ticket: Create a Credit Note)

Issue:
=> The credit note is not of the same amount = 106.80. That is, MINUS discount * tax_amount <-> 108.90 MINUS 10% * 21= 106.80

Cause:
When there is a "Separate discount accounts on invoices" that is set, discount line appear on the journal items of the document; moves between the default account for such transaction to the chosen move in the settings.
When iterating through those discount lines, the condition was not strict enough to filter them out and would put a tax on them (as my dear colleague Andrea said: the bomb has been planted)

Therefore, when creating a credit/duplicating,  we copy the data  wrongly (but in a correct a way for a standard flow) which gives incoherent results

opw-4166601

Forward-Port-Of: odoo/odoo#187565

## Description
Following ef90c22efda8a1d56d41eb0739d94733fb574f41, the delegated `_name_search` on `product.product` executed when performing a `name_search` on `product.template` is always unbounded (no limit). For non-selective domains on large databases, this can lead to manipulating extremely large lists of IDs, which are re-injected into other queries, resulting in performance regressions and excessive Postgres memory consumption.

We introduce an upper bound on the delegated `_name_search`. To avoid excessive iterations when there is no limit, the bound is set large enough but not so large that it causes blocking regressions. Each iteration becomes more selective than the previous one, as already found templates are excluded from the search scope.

## Benchmark
On a database with over half-million active products, a non-selective `name_search` that matches 1/3 of the products (For ex: `name='d', args=[('sale_ok', '=', True)]`, which happens during via dropdown of products on a `sale.order`):

|               | Before           | After |
|---------------|------------------|-------|
| Timings (hot) | 15min+ (timeout) | 50ms  |

## Reference
opw-4448182

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

Forward-Port-Of: odoo/odoo#193448
Forward-Port-Of: odoo/odoo#193293