Purpose:
--------
This commit adds some tests for the room application which currently has almost none.

It also fixes some issues that were pointed out by writing these tests:
- Fix reactivity of the booking form view: when a notification of a booking update was received during the edition of a booking, its duration was changed in the sidebar but not in this form view.
- Fix luxon locale desync: since the redesign of the frontend view, the locale used when loading the existing bookings was not the same as the one used after it.
- Fix current week in the form view: the week was not updated when clicking on a booking in the sidebar while already in the form view.
- Fix remaining time flicker: when a booking ended, the remaining time could be minus 1 second for a split second.
- Fix remaining time reactivity: when a booking started immediately after that another one ended, the remaining time shown was not updated at the same time than the sidebar and current booking title.

Task-3609006

When making a cross_report aggregation expression, its date_scope is going to be enforced on all expressions used in its computation. Because of that, if an expression of the current report is referenced by such an aggregation, and if this forced date_scope is different from that expression's, this expression will be computed twice, once for each date_scope. However, the modelling of the report makes it so that the second of these computations will overwrite the result of the first one (because the expression totals dict uses expressions directly as its keys). For now, this case is considered unsupported, as its is not common at all, and an easy workaround exist (just use multiple aggregation expressions, and only reference other reports in cross_report expressions). We hence add an exception in the report computation to crash when it occurs instead of displaying potentially wrong amounts.

We also fix the NDays expression of the Executive Summary, as they were facing this situation, and hence raised the new exception we introduce here when the report was tested. Though it was a bit useless to compute them twice like that, their custom engine was made in such a way that the result of the computation was unchanged, so we can safely change the date_scope here so that it matches the one used on the aggregations calling them.

Forward-Port-Of: odoo/enterprise#55212

Before this commit:
When the user creates new stages or groups in Kanban view and adds new tasks with particular states and then if the user clicks on any colour in the progressbar then the filter gets applied on all the groups or stages.

Observerd Behaviour:
The filter is applied on all the groups or stages.So, if we click on a colour in the progressbar suppose colour Green to filter out Approved task(s) of a particular stage then in that stage or group only the Approved task(s) would be visible. Also the filter would get applied on all other stages or groups created at that time. In those stages all the task with that state would be visible and rest of them would get blurred.

Steps to produce:
- Install `Project` and add a new project in it.
- In the newly created project add some new stages or groups, each consisting some new tasks.
- Give some states to those tasks through project state selector (for eg: Approved, Changes Requested).
- Click on any particular colour in the `Progressbar` of any particular group or stage.

Expected Behaviour:
When the user clicks on any colour in the progressbar then it should filter out only those tasks which are associated with that color/state and only in that particular group or stage.

Reason:
https://github.com/odoo/odoo/blob/579ee6d9792050955fa80346fd57ad294efcdd62/addons/web/static/src/views/kanban/progress_bar_hook.js#L114 group.serverValue results as Undefined. Because when the data is being prepared here:
https://github.com/odoo/odoo/blob/493d5c39982de79e6fb256dd8084bf592a740f77/addons/web/static/src/model/relational_model/dynamic_group_list.js#L222-L231 there is no serverValue provided. So, whenever a group is getting created here serverValue `Undefined` as value.
https://github.com/odoo/odoo/blob/493d5c39982de79e6fb256dd8084bf592a740f77/addons/web/static/src/model/relational_model/group.js#L25

Note:
- There was a need to change the function name from
`getServerValueFromGroupData` to `getGroupServerValue` as now now this function
calculates serverValue while the data is being created and not when the data is
already created.
- The function is exported into another file as this function defines the basis
to calculate serverValue and there is a necessity to calculate serverValue while
data is being created.

Task-3620697

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

Issue: When purchasing tickets for an event, if the quantity of tickets is reduced directly from the cart, payment can be processed for the reduced number of tickets while the excess registrations remain incorrectly open in the database.

Steps to Reproduce:

1 Install Events Online Ticketing.
2 Create or select an event with open registrations. 3 Add 3 registrations to your cart and proceed to checkout. 4 In the payment process, go to 'Review Order' and reduce the quantity of tickets.
5 Complete the checkout and payment.
6 Upon inspecting the database for the same event, you'll notice an inconsistency: the number of attendees is higher than it should be.

Solution:
This issue arises from the implementation of
`_compute_registration_status`, which only considers the sale order line and marks registrations as cancelled only if the entire order line is cancelled. This means either all 3 registrations are cancelled, or none. The solution introduced here addresses this by checking for registrations already marked as cancelled and incorporating them into the cancellation logic, ensuring accurate tracking of active and cancelled registrations.

opw-3653452

Since the introduction of the Embed Code snippet with [1], in case some
content was created dynamically through a `<script>` tag, it would be
duplicated upon editing the snippet again after it had been displayed a
1st time. This is because each time you open the snippet's ace editor,
the current state of the snippet (including dynamically created
elements) is saved in the view.

This commit removes the `<script>`s inside embed code snippets from the
view in edit mode, and then saves them on the server upon save.
We also take the opportunity to add a message in edit mode if the
snippet doesn't display anything (e.g. if it only contains a script tag,
or an empty element), so that it is easily focusable to edit its
content.
Finally, we add a message upon editing an embed code snippet to inform
the user that they should not use it unless they know what they're doing
as well as tell them they may inject code in the `<head>` or `<body>`
elements through the Theme panel.

Note: this fix is only valid for code injected inside the embed code
snippet. For code injected outside of the snippet, we have no way of
controlling / sanitizing the DOM after the fact.

Steps to reproduce:
1. Drag and drop an Embed Code Snippet
2. Copy the following code:
```
<script>
document.addEventListener('DOMContentLoaded', function () {
const alertEl = document.createElement('div');
alertEl.classList.add('alert', 'alert-primary');
alertEl.textContent = "Hello";
document.getElementById('some-stuff').appendChild(alertEl);
});
</script>

<div id="some-stuff"></div>
```
3. Save and exit the editor. The injected div should appear.
4. Go back to the editor, click to edit the snippet and either save or
discard.
5. Exit the editor
=> The div is duplicated.

[1]: https://github.com/odoo/odoo/commit/2cc481d1a62202ade4c1ca8f846c962f9f2cc34d

opw-3513760

Forward-Port-Of: odoo/odoo#152426
Forward-Port-Of: odoo/odoo#142130

This PR fixes 2 issues with discuss navigation:

1. Broken backwards navigation when going back and forth from the live
chat session history.
2. Broken backwards navigation when trying to access the same thread
than the current one.

Steps to reproduce 1:
- Open the command palette
- Go to the live chat session history view
- Click on one of your channels
- History back => leads to the session history view
- History forward => leads to discuss
- History back => stays on discuss, history is broken

This occurs because the active id is not passed in the action context
when navigating backwards which leads to the URL being pushed again in
history (URL without active id is different). The active id should be
put in the context when available.

Steps to reproduce 2:
- Go to discuss
- Click on the active thread
- History back => stuck on discuss, cannot navigate backwards anymore.

We should not push in history when accessing the same thread than the
current one.

task-3422516

Forward-Port-Of: odoo/odoo#152423

In previous versions the max size of a domain was bounded by psycopg memory limits. With the new SQL formatting mechanism the limit is bound by the maximum recursion limit in Python side. The purpose of this patch is to restore previous behavior.

In 16.0:
```
>>> def make_dom(N):
...     return [*('|' for x in range(N-1)), *(('login', '=', 'admin') for x in range(N))]
...
>>> u.search(make_dom(9984))
res.users(2,)
>>> u.search(make_dom(9985))
Traceback (most recent call last):
  File "<input>", line 1, in <module>
    u.search(make_dom(9985))
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 1520, in search
    return res if count else self.browse(res)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5140, in browse
    if not ids:
  File "/home/odoo/src/odoo/16.0/odoo/tools/query.py", line 217, in __bool__
    return bool(self._result)
  File "/home/odoo/src/odoo/16.0/odoo/tools/func.py", line 28, in __get__
    value = self.fget(obj)
  File "/home/odoo/src/odoo/16.0/odoo/tools/query.py", line 210, in _result
    self._cr.execute(query_str, params)
  File "/home/odoo/src/odoo/16.0/odoo/sql_db.py", line 321, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.SyntaxError: memory exhausted at or near ""login""
LINE 1: ...((("res_users"."login" = 'admin') OR ("res_users"."login" = ...
```
in 17.0 without this patch
```
>>> u.search(make_dom(1480))
res.users(2,)
>>> u.search(make_dom(1481))
  <shortened output ...>
  File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
    child = stack[-1].send(child)
  File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 86, in <genexpr>
    if isinstance(child, SQL):
  File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
    child = stack[-1].send(child)
  File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 86, in <genexpr>
    if isinstance(child, SQL):
  File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
    child = stack[-1].send(child)
  File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 86, in <genexpr>
    if isinstance(child, SQL):
  File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
    child = stack[-1].send(child)
RecursionError: maximum recursion depth exceeded
```

This issue was observed in upgrades in multiple instances. Example: MRP produces an OR domain with 2K terms for warehouse sub-locations that fail.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Issue:
When the notification webhook is enabled for Adyen, sometimes the response back causes an SQL concurrent update. Odoo then creates a retry towards Adyen, charging the customer card several times. Both the notification webhook and the payment controller are hit, and try updatingthe same row simultaneously, which causes this behavior.

Steps to reproduce:
This bug is not reproducible due to a connection issue for the Adyen test account. However, if the payment request would implement idempotency we could prevent billing the customer on the same request if the request reaches this collision and is retried multiple times.

Description
A first payment request is sent to Adyen. The card is charged and Adyen answers that all went as expected.
We try to process the payment, but a concurrent access error occurs.
A retry is done.
A payment request is sent again to Adyen, The card is charged AGAIN and Adyen answers that all went as expected.
We try to process the payment, but a concurrent access error occurs.

For each retry, the request is sent and the card is charged.

If the first retry succeeds, then Odoo can finish the process. There will be only 1 payment transaction on Odoo's side
(others have been rollbacked) but there will be 3 on Adyen's side and the card will be charged 3 times.

This PR fixes this behaviour by adding the idempotency key to the headers with the hash of the transaction
reference and the database UUID, we prevent duplicate payments to happen.

OPW-3584300

Forward-Port-Of: odoo/odoo#152760
Forward-Port-Of: odoo/odoo#150102