(note for reviewer: I reset my branch on 15.0)

The `werkzeug.proxy_fix.orig` is set when running in --proxy-mode, it holds the original value of various headers before the ProxyFix class changed them according to the `X-Forwarded-` headers.

It is a dictionnary with the following entries:

    orig_remote_addr = environ_get("REMOTE_ADDR")
    orig_wsgi_url_scheme = environ_get("wsgi.url_scheme")
    orig_http_host = environ_get("HTTP_HOST")
    "werkzeug.proxy_fix.orig": {
        "REMOTE_ADDR": orig_remote_addr,
        "wsgi.url_scheme": orig_wsgi_url_scheme,
        "HTTP_HOST": orig_http_host,
        "SERVER_NAME": environ_get("SERVER_NAME"),
        "SERVER_PORT": environ_get("SERVER_PORT"),
        "SCRIPT_NAME": environ_get("SCRIPT_NAME"),
    }

All those sub-entries are already allow-listed by the Odoo's HTTPRequest class.

Accessing those values is handy when debugging the --proxy-mode, it allows to see at a glance if the proxy-mode was effective for this request: the `werkzeug.proxy_fix.orig` entry is present; or not: the entry is absent.

Forward-Port-Of: odoo/odoo#169566
Forward-Port-Of: odoo/odoo#168841

### Steps to reproduce:

- Create a storable product P with a BOM with two raw lines:
	- 1 unit x COMP 1
	- 1 unit x COMP 2
- Create and confirm a manufacturing order for 1 unit of P
- Click on the list icon of the stock move of COMP 1 and close the x2many dialog tab with cancel
- Change the qty_producing of the MO to 1 and then click anywhere on the form of the MO to trigger the associated onchange

### Cause of the Issue:

Clicking on the list icon of the stock.move will trigger the `extendRecord` method:
https://github.com/odoo/odoo/blob/f8182fb625eb3e20c85388d4c342553af4fe7ab9/addons/web/static/src/model/relational_model/static_list.js#L195-L198 This trigger will then add the `move_line_ids` to the fields and active fields of the stock.move of COMP 1.
Closing the x2many dialog and changing the `qty_producing` of the mo will then trigger this onchange call:
https://github.com/odoo/odoo/blob/f8182fb625eb3e20c85388d4c342553af4fe7ab9/addons/mrp/models/mrp_production.py#L806-L807 This one will update the stock move values of both components. However, the stock move associated to COMP 2 was not extended and the `move_line_ids` field that record will be accessed to determine its invisible attribute:
https://github.com/odoo/odoo/blob/f8182fb625eb3e20c85388d4c342553af4fe7ab9/addons/web/static/src/model/relational_model/static_list.js#L546-L547 Since the result is undefined a client error is thrown.

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

Forward-Port-Of: odoo/odoo#167217

Issue:
======
Clicking enter in a banner inside a list breaks the layout in chrome browser.

Steps to reproduce the issue:
=============================
- Open chrome browser
- Go to to-do
- Create a list  and add 1 item
- Click enter (Second element of the list) and add a banner in the item
- Click enter
- Doesn't work as expected

Origin of the issue:
====================
This is a browser issue, chrome in this specific case doesn't work properly, all the events until `textInput` are called when clicking `enter` but the last event is never triggerged which is the `input` event. The specific case can be reproduced with this:
```
<div contenteditable="true">
     <ul>
         <div contenteditable="false">
             <div contenteditable="true">
                 <p>
                     text[]
                 </p>
             </div>
         </div>
     </ul
</div>
```

Solution:
==========
We manually trigger the `input` event in this specific case.

Issue:
======
List inside a banner under a list doesn't align correctly

steps to reproduce the issue:
=============================
- Go to do
- Add a list and first item
- Add a banner
- Add a list inside the banner
- It's not correctly centered

Origin of the issue:
====================
Since the list inside the banner is considered nested list under the top
list, the `margin-bottom` is removed.

Solution:
=========
Reassign the style again when we are inside the banner.

task-3857296

Forward-Port-Of: odoo/odoo#162204

Have a list view grouped by 2 fields (e.g. Contacts: Salesperson >
name). Open a group which contains more groups than the limit (set the groups_limit attribute on the arch if necessary). Next to the name of the group, the total number of records belonging to that group is displayed (e.g. Mitchel Admin (32)). In the group header row, the pager allows to browser the inner **groups**, so the total displayed there is the total number of inner groups in that group (e.g. 1-10 / 31).

From that point, clicking on a column header to sort by a given field produces a reload, and the group pager is updated with the wrong total: it now displays the number of records, not the number of groups (1-10 / 32 in the example).

This commit fixes that issue.

The test also hihglighted another issue: when reloaded, we sometimes have to keep former groups that became empty and that weren't returned by the last call to web_read_group (e.g. we drag and dropped the last record from a group to another group). We only do that if search query parameters didn't change. However, we forgot to take the orderBy into account, so when sorting groups, groups that were no longer on the current page were still displayed, with count 0. This commit also fixes that issue.

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

Forward-Port-Of: odoo/odoo#170099

Improve runtime of `stock.forecasted_product_product._get_report_lines` by reducing total query count, as well as some other minor optimizations.

Reduce query count of `_get_report_lines` by:
1.) Introducing and utilizing two new `stock.move` methods, `_rollup_move_dests_fetch` and `_rollup_move_origs_fetch`. (More details below)
2.) Share _prefetch_ids between linked moves. By grouping their prefetching together we will ensure that fewer unnessesary queries will be made. Without doing this, then for N linked moves there would be at least N queries for each linked move during all the calls to `_get_out_move_reserved_data`. With prefetching we are at least making N/1000 queries, which is much better. Ultimately, it would be most optimal to use `.read` to make only one query up front - but this would likely require a total rework of much of the code in `stock.forecasted_product_product` (as well as modules which inherit from this). Prefetching is much simpler for now, and the gains are good enough to warrant doing it.
3.) Call `fetch` to get the `state` and `quantity` fields from all sibling moves. These could instead be added into the consolidated prefetch_ids. Maybe that is more preferable, but I think `fetch` here is OK because we only need those two fields from the sibling moves.

Other minor optimizations include:
1.) Use sets instead of recordsets where it would make sense to do so. Because, when the `in` operator is used, it is more efficient to use set's `in` (O(1)) vs recordset's `in` (O(N)).
2.) Use `._ids` instead of `.ids` where we can get away with it. In places where we are have freshly searched recordsets, there is no possibility for any NewIds to be present. So it should be safe to use `._ids` here, which avoids some extra constant time work that `.ids` would impose.

`_rollup_move_x_fetch` (x is dests or origs):
These methods are intended to be used to reduce the total number of queries made in situations where you have N moves and you need to call `_rollup_move_x` on all of them. If you do this, for each move you call rollup on, you'd make O(len(P)) queries where P is the longest "path" formed in the tree of moves. Since you do this N times, you'd end up overall with O(N*len(P)) queries. If you call `_rollup_move_x_fetch` on a recordset containing all N moves, it loads all of the moves into the cache that would have to be loaded if you call `_rollup_move_x` on all of them individually. The number of queries `_rollup_move_x_fetch` makes for N records is only O(len(P)), because it is able to traverse the move tree in a breadth first manner for all nodes, loading as many as is possible at each step. Since len(P) is likely to be small for any given database (citation needed), you could effectively consider it constant O(1). Even in the worst case, where all the moves only form a single long path, len(P) will be at most N. Once you then call `_rollup_move_x` on each individual move, because all the moves are already loaded into the cache it will make 0 queries. This leaves us with the following conclusion: `_rollup_move_x` alone is ~O(N) queries, and `_rollup_move_x` with `_rollup_move_x_fetch` beforehand is ~O(1) queries. In the worst case described where len(P)=N, it will degrade to O(N), which would not be any different than before.

Benchmarks:
In the customer's database locally, (after re-adding `components_availability` and `components_availability_state` to their view, which was removed previously as a work-around):

Log line stats for loading the manufacturing order list view:

|                               | # queries       | SQL time     | Odoo time | total time     |
|-------------------------|--------------------|------------------|-----------------|-------------------|
| before commit   | 149128           | 23.736 s       | 46.842 s     | 70.578 s       |
| after commit      | 144                  | 0.914 s         | 11.335 s     | 12.249 s       |
|                               |                         |                       |                     |                       |
| % improvement |  ~915x fewer | ~26x faster  | ~4x faster  | ~5.7x faster |

Before and after commit pretty much all of the Odoo time of the request is spent in `_get_report_lines`, so I don't think it's necessary to provide benchmarks seperately for this function.

Help Ticket # to see also which exhibit this issue:
3818495
3918816
3920584
3935316

opw-3769280

Forward-Port-Of: odoo/odoo#167806

Versions
--------
- 15.0+

Steps
-----
1. Sync with Google Calendar;
2. create a recurrent all day event in google calendar;
3. make sure it shows as "busy";
4. make an appointment via website on that day.

Issue
-----
You are allowed to make an appointment on slots that overlap the synced event.

Cause
-----
Recurrent day events synced via Google Calendar have their start & end date equal to each other, so the event's "end date" could be 24 hours before the actual end.

Commit ad4219876cee4f4b996a7cc72fd176b51be3a063 added an the `_slot_availability_prepare_values_meetings` method, optimized to not include conditions on `start_date` and `allday`. Instead, it filters event by date ranges.

In our scenario, an `allday` event with start & end dates set to something like `2022-02-14 00:00:00`, may get excluded from the search when this is also the value of the starting point of the search, due to `stop` not being strictly greater than the starting point.

Solution
--------
Do an inclusive range search instead of an exclusive one.

opw-3793009

Forward-Port-Of: odoo/enterprise#65023
Forward-Port-Of: odoo/enterprise#63761

# How to reproduce
- Create product: P1, storable | tracked by lot | barcode set
- Create Receipt for 2 units of P1
- In barcode App:
  - Scan product "P1"
    - Scan lot "lot1"
    - Scan lot "lot2"
  - Select line with "lot1"
  - Scan dest location "2601892" (Stock/Shelf1 in runbot)
  => New line created for P1 with quantity 0

https://github.com/odoo/enterprise/assets/29302288/2892a5dc-43e7-4437-9eb7-c079d1b2f807

The selected line is always done first.
Usually the selected line is the last one without reserved quantity, it is not split, and we steal the reserved quantity of the sibling.
However, if the line with incomplete reserved quantity is done first, then it is split. When the next line is done, it steals quantity from the created line, leaving it with reserved_uom_qty = 0 and qty_done = 0.

---

To fix this issue, we assign the reserved quantity from the sibling on all lines before changing the dest location and doing a split.

OPW-3942171

Forward-Port-Of: odoo/enterprise#64592