Before this commit, the autocomplete dropdown of a many2one could open again right after a suggestion was picked, and stay open. The step of mail_template_dynamic_placeholder_tour waiting for it to close then times out:

    FAILED: [8/36] Tour mail_template_dynamic_placeholder_tour
    Step Wait for the drop down to disappear
    (trigger: div[name="model_id"] .o-autocomplete:not(:has(.ui-autocomplete)))
    TIMEOUT step failed to complete within 10000 ms.

This happens because the search filling the dropdown runs 250ms after the last keystroke, so a suggestion of the previous search can be picked while the next search is still scheduled. Picking a suggestion only closes the dropdown. The scheduled search then runs, opens the dropdown on the selected value, and nothing closes it after that.

This commit fixes the issue by discarding the scheduled search when the dropdown closes.

https://runbot.odoo.com/odoo/error/233574
https://runbot.odoo.com/odoo/error/237744
https://runbot.odoo.com/odoo/error/944454
https://runbot.odoo.com/odoo/error/945517
https://runbot.odoo.com/odoo/error/947141

Forward-Port-Of: odoo/odoo#290317
Forward-Port-Of: odoo/odoo#287888

Steps to reproduce:
* Install **Accounting** module.
* Create a Belgian partner.
* Assign a VAT number (e.g. BE0477472701).
* The BCE/KBO field in Multi ID is correctly populated.
* Modify the VAT number.

Observed behavior:
* The BCE/KBO (BE_EN) in Multi ID keeps the old value.

Cause:
* `_deduce_additional_identifiers_from_vat` skipped any identifier key that already existed in `additional_identifiers`: new_identifiers = {k: v for k, v in deduced.items() if k not in identifiers}
* On the first VAT save, BE_EN is written correctly.
* On subsequent VAT changes, BE_EN already exists, so the condition short-circuits and the old value is preserved.

Fix:
* Replace the key-presence guard with a value-equality check so that deduced identifiers are always overwritten when their value would change: updated = {k: v for k, v in deduced.items() if identifiers.get(k) != v}
* Since BE_EN is fully derived from the VAT (it is the VAT with the country prefix stripped), it must always mirror the current VAT.
* The Peppol endpoint is already declared as depending on `additional_identifiers`, so it recomputes automatically once BE_EN is corrected — no further change needed there.

opw-6545770

Forward-Port-Of: odoo/odoo#288057

When we setup a many2many field which is not stored, it must not have a relation. This is already done for nonrelated fields, but we must do it also for related fields. Otherwise, we may have side-effects like finding sibling fields in 20.0: in the code below, reading categories would fill roles.

```py
model_id = self.env["ir.model"]._get("test_new_api.foo")
fields = [{
    "name": "x_partner_id",
    "ttype": "many2one",
    "relation": "res.partner",
}, {
    "name": "x_role_ids",
    "ttype": "many2many",
    "relation": "res.partner.category",
}, {
    "name": "x_partner_category_ids",
    "ttype": "many2many",
    "relation": "res.partner.category",
    "related": "x_partner_id.category_id",
    "store": False,
    "readonly": True
}]
for f in fields:
    f["model_id"] = model_id.id
self.env["ir.model.fields"].create(fields)
env['test_new_api.foo']._fields['x_partner_category_ids'].relation  # should be None
```



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

Forward-Port-Of: odoo/odoo#290286
Forward-Port-Of: odoo/odoo#290067