Before this commit, if chatbot had ampersamd character in question answers, this would lead to following crash:

```
Cannot read properties of undefined (reading 'id')
```

Steps to reproduce:

- configure chatbot with following step scripts:

```
 Message | step type | answers                   | only if
---------+-----------+---------------------------+----------------
 step    | question  | "test & step 2", "step 3" |
 step 2  | text      |                           | "test & step 2"
 step 3  | text      |                           | "step 3"
 ```

- open conversation with chatbot
- select "test & step 2" => crash

This happens because when selecting an answer, chatbot detects the selected answer by comparing user message content with all possible answer text content. The message body of user is escaped, whereas chatbot answers are not. Thus `test & step 2` is not found and therefore the crash results in `answer.id` where `answer` is `undefined`.

This commit fixes the issue by escaping the value of answer in the detection of selected answer by user, so that escaped content is compared with escaped content too.

opw-4369966

Currently, an error occurs when generating a payment link for an invoice without add an invoice line.

Step to produce:

- Install the ```account_payment``` module.
- Create a new invoice, Click on the 'Actions' button, and try to generate a payment link.

See Traceback:

```
KeyError: 'amount_due'
  File "odoo/http.py", line 2363, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1891, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1954, 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 1921, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2168, 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 "addons/web/models/models.py", line 867, in onchange
    defaults = self.default_get(missing_names)
  File "addons/payment/wizards/payment_link_wizard.py", line 22, in default_get
    self.env[res_model].browse(res_id)._get_default_payment_link_values()
  File "addons/account_payment/models/account_move.py", line 105, in _get_default_payment_link_values
    amount_max = next_payment_values['amount_due']

```

An error occurs when the system attempts to get the next payment value at [1], But there is nothing to pay as an invoice line is not available.

Link [1]: https://github.com/odoo/odoo/blob/288d3926c5d011590aa25e9886cfa36377974dd6/addons/account_payment/models/account_move.py#L104-L105

To handle this issue, return an empty dictionary if the invoice line has not been added.

Sentry-6078809446

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

If we replace the original definition then the check between the existing definition and the original one will always fail, thus we are always removing and re-adding the same constraint. https://github.com/odoo/odoo/blob/5ba361ddffa757cf60968f37180c7fd1304b3fd4/odoo/models.py#L3209

Replacing `%` by `%%` works for `LIKE` operator because they are equivalent. Since they are sent as-is to the DB the constraint could actually be plainly wrong.

```sql
test_17=> SELECT coalesce(d.description, pg_get_constraintdef(c.oid))
   FROM pg_constraint c
   JOIN pg_class t
     ON t.oid = c.conrelid
   LEFT JOIN pg_description d
     ON c.oid = d.objoid
  WHERE t.relname = 'ir_model_fields'
    AND conname = 'ir_model_fields_name_manual_field'
+------------------------------------------------+
| coalesce                                       |
|------------------------------------------------|
| CHECK (state != 'manual' OR name LIKE 'x\_%%') |
+------------------------------------------------+
```

Example where the definition sent to the DB is wrong:
```py
class A(models.Model):
    _inherit = "res.users"

    _sql_constraints = [("test_constraint", "CHECK (login !~ '%')", "Cannot have % in login")]
```
```sql
test_17=> \d res_users
...
Check constraints:
    "res_users_test_constraint" CHECK (login::text !~ '%%'::text)
...
```

Since 18.0, we adapt the `SQL` object so that composition with code containing '%' works and we accept single unescaped '%' if there is no arguments.

X-original-commit: 692ad8e8a969981c6171b7bef34dfee5f0b007f8

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

To reproduce the issue:

- Enable Avatax in Accounting settings
- Go to the 'All' product category and set Avatax Category '[D0000000] Digital goods'
- Create a subscription order and set Deco Addict as the customer (is exempt)
- Set the Avatax fiscal position
- Confirm the order
- Preview in portal view
- Notice the tax is not equal

The subscription portal view was changed in #49963 to only display lines to be invoiced. So non-recurring lines were no longer shown. Because of this, the regular `tax_totals` field cannot be used in the portal anymore. Tax totals need to be recomputed for just those lines. This was done in a new method: `_next_billing_details()`.

This method recomputes tax totals using account.tax records, which won't be correct in many cases when using an external tax calculator. The percentage field that we set on the tax is only informational, and won't take exemptions into account.

Up to this point, the issue was only cosmetic. The customer was still charged the correct amount. This changed in #72120. Instead of charging `amount_to_invoice`, it now charges the amount calculated by `_next_billing_details()`. This, as stated above, won't always be correct.

To resolve the problem we first override `_next_billing_details()` so that it returns `tax_totals` based on line amounts. Those fields are the authoritative amounts that we set during external tax calculation [1]. This solves the cosmetic issue described above in most cases. However, the wrong totals are still displayed right after paying a subscription. This happens because the payment changes the state of the subscription, which invalidates the line amounts and recomputes them from `account.tax` again. We already overrode the `/my/subscriptions` controller to insert an external calculation and avoid this, but it happened after `super()` which is too late. At that point `_next_billing_details()` is already evaluated, with the incorrect values already in `qcontext`. To solve that we move the call before `super()`.

We also change `next_amount_invoice` to be the sum of invoicable lines, again basing this total on the authoritative amounts returned by the external tax calculator. We cannot use `amount_to_invoice` like before, because that breaks the "Anticipate payment" feature which was fixed in #72120. This solves the issue of charging the wrong amount.

opw-4315535
opw-4363065

[1] https://github.com/odoo/enterprise/blob/84aa5e2fb064bc0366e952cbd4eaf3628ea24b73/sale_external_tax/models/sale_order.py#L43-L55

PR note: built on top of #73921