This PR introduces a local upgrade script to fix the duplicate UUID issue for customers who upgraded to 18.0 before this PR was merged:

#194990 

The creation of this local upgrade script was requested towards the end of the conversation on that PR.

Before the above PR was merged, older POS [order, order.line, payment] records all got the same UUID during the upgrade to 18.0 for the reason laid out in the conversation on the PR:
> [in reference to the default value for the uuid column calling `uuid4()`] ... when the ORM inits the column it will set the same value for all rows.

Current behavior before PR:
Post-upgrade POS tickets get sent to Tech for us to clean manually via a server action that duplicates UUIDs.

Desired behavior after PR is merged:
Post-upgrade POS tickets can be solved in Functional by "Upgrading" the `point_of_sale` module **or** the customer doesn't need to create a ticket because they solved it themselves by upgrading their module.

Forward-Port-Of: odoo/odoo#201287
Forward-Port-Of: odoo/odoo#200067

Nothing prevents from creating templates and composers on non thread
models. However most necessary code relies on mail.thread.

Here we move code from mail.thread directly to BaseModel. For most
business models it does not change anything. For some side models
it allows / fixes usage of SMS composer, allowing to dynamically
find numbers / partners, ...

One notable use case that triggered this PR is sending of SMS to
users using their work phone number, or through their partner. Either
we hack user model, either we provide a generic fix.

Note that in current master (18.2+) most 'mail' generic features are
supported on non-thread models (template usage and sending, mailing
using composer, ...). SMS is still thread-specific while phone
capabilities have already been moved to generic code.

We therefore continue towards generic simple mail / sms usage on
business records, while advanced features (followers, logs, direct
post using SMS type) require thread-enabled models.

Task-4113190
sentry-4681535519

Forward-Port-Of: odoo/odoo#202913
Forward-Port-Of: odoo/odoo#200650

Description of the issue this commit addresses:

When registering a SEPA payment, it is possible to get a UserError telling you
to validate therecipient bank account while it is validated.

---

Steps to reproduce:

1. Install account.
2. Activate SEPA Credit Transfer (SCT) in the settings.
3. On the Bank journal's settings, input an account number.
4. Make sure the accounts used for the transfer authorize sending money.
5. Create a move in the misc journal with multiple lines and distinct partners.
6. Post the move. Go in the journal entries. Select it. "Register Payment".
7. Change the Payment Method for SEPA Credit Transfer. "Create Payments".
8. A UserError shows up.

---

Desired behavior after this commit is merged:

No UserError shows up, the payments are created.

---

Note on the fix:

The error happened because one of the condition for raising the UserError is a
value of a record in a many2one relation which is a stored computed field. As
the payment is created with a list of values, the compute method is not
triggered and the many2one remains empty while it should not.

This fix makes sure the partner_bank_id is only put in the payment values once
it has been computed to avoid keeping it false.

---

opw-4518374

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

Forward-Port-Of: odoo/odoo#203003
Forward-Port-Of: odoo/odoo#201608

**Steps to reproduce:**
- Install Accounting and l10n_ke_edi_tremol
- Switch to a Kenyan company (e.g. KE Company)
- Configure USD currency:
  * Rounding Factor: 0.000100
  * Decimal Places: 4
  * Rate: 0.007729205731 Unit per KES 129.379400000000 KES per Unit
- Create a product with decimal in the price (e.g. 1234.56)
- Create an invoice:
  * Customer: [a Kenyan customer]
  * Currency: USD
  * Product: [the created product]
  * Taxes: 16%
- Confirm the invoice
- Send the invoice to fiscal device (It will not be possible without some credentials. However, if a breakpoint is set at the last line ("return" line) of "_l10n_ke_cu_lines_messages" method, the total amount in KSh sent to the fiscal device can be checked.)

**Issue:**
The total amount in KSh sent to the fiscal device is different than the total amount in USD converted to KSh with the used currency rate.

**Cause:**
In the "_l10n_ke_cu_lines_messages" method (the method used to compute the amounts sent to the fiscal device), a rounding is done by forcing the number of decimal to 2 without taking into account the configuration of the currency when computing the price.

opw-4567098




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

Forward-Port-Of: odoo/odoo#202998
Forward-Port-Of: odoo/odoo#202706