### Steps to reproduce:

- In the settings enable Multi-Steps Routes
- Put your warehouse in manufacture in 3 steps
- Create a storable product P
- Create and confirm an MO for 1 unit of P
- Go to Inventory > Operations > Procurement > Replenishment
- Create a new one for P in WH/stock
#### > The forecasted quantity in stock is still 0 but should be at 1, just as if the the MO had been generated using the    replenishment for 1 unit

### Cause of the issue:

When an MO is created using a procurement, a `location_final_id` is set to WH/Stock on the MO and propagated on the move for the finished product:
https://github.com/odoo/odoo/blob/8d4e6df0c0ac5ebc6362f3578ae8cc8edf4a76f7/addons/mrp/models/stock_rule.py#L165 https://github.com/odoo/odoo/blob/8d4e6df0c0ac5ebc6362f3578ae8cc8edf4a76f7/addons/mrp/models/mrp_production.py#L1169-L1175 As such, even if the manufacturing is now handled in push, this move will contribute positively to the forecast in the `virtual_available` quantity of the product in WH/Stock bevause of the `location_final_id`. By contrast, if hte MO is created by hand, it does not bear a `location_final_id` so that the MO can only contribute to the stock forecast has been processed and the related internal transfer `WH/post-prod -> WH/Stock` is created.

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

Forward-Port-Of: odoo/odoo#221462
Forward-Port-Of: odoo/odoo#221003

*: pos_restaurant, pos_online_payment_self_order, pos_self_order

When self-ordering is enabled and in pay after each mode, the table
selection was handled via table_id fields, which caused issues when a
customer had an issue with its payment and wanted to pay later. It was
blocking the table with its order, so if another customer wanted to
scan the same QR code, it would not be able to add anything to the cart.

Now in pay after each mode, the table selection is handled via
floating_order_name, which allows the order to be processed without
blocking the table. This way, the table can be reused for another
customer, and the order can be paid later.

---

Regarding direct sale in `point_of_sale`, when a customer wanted to pay
by card the order was synced with the server when the waiter clicked on
the payment method, if the direct sale had no table and no floating
order name, when synching on other devices the order was blocking them.

Now if no table and no floating order name is set, when synching the
order, the pos_reference is set to the floating_order_name, which
prevents the order from blocking other devices.

---

Regarding self order cancellation from a PoS, when the waiter was
cancelling an order it was not synced with the self-order app, which
caused the self-order app to keep the order in the cart, preventing the
customer from starting a new order.

---

Regarding self order ticket printing, when an order arrives on the PoS
to be printed, we were trying to print the preparation ticket and
the customer ticket at the same time, which caused issues with the
printing. Now we printing them one after the other.

Steps to Reproduce:
1. Go to the website.
2. Create a new menu (e.g., 'Test 1') using the 'Edit Menu' option and add it under another menu (e.g., 'Contact Us'), creating a sub-menu. 
3. Turn on the developer mode.
4. Go to Configuration -> Menus and add two menus (e.g., 'menu 1' and  'menu 2') under the new sub-menu (e.g., 'Test 1').
5. Notice that the two menus ('menu 1' and 'menu 2') are not visible on the website.

Description:
As per functional specifications, creation of multi-level sub-menus should not be allowed.

Key Changes:
raises a `UserError` if a menu exceeds the two-level hierarchy by checking the parent and grandparent levels.
- Implements mega menu restrictions:
    - A mega menu cannot have a parent menu.
    - A mega menu cannot have child menus.
    - Any menu cannot be a child of a mega menu.
- Prevents menus with child menus from being added as submenus to existing menus.

This ensures that the website menu structure adheres to the defined functional specifications, providing a consistent and predictable user experience.

task-3901371

Forward-Port-Of: odoo/odoo#222254
Forward-Port-Of: odoo/odoo#168801

Currently below error occurs while archive/unarchive company:
- Company list is not being updated.
- In `hr_timesheet` KeyError will be encountered on unarchiving a company.
- In `l10n_it_pos` module an AccessError will be encountered on unarchiving a company.

**Root Cause:**
Since https://github.com/odoo/odoo/commit/22e9d822e8cab08114c006eb8c4054c4de0c40f2, the `session_info` method relies on `user_companies` at [1], which fetches only
active company IDs via `_get_company_ids()`. However, `_get_company_ids` uses caching as
shown at [2]. When a company is archived or unarchived, 'write' method is called. Now, here
the cache is invalidated before writing to the company as shown at [3]. Due to which
'_get_company_ids' method doesn't receive the updated list of companies, causing this issue.

**Solution:**
This commit prevents error by ensuring companies are stored before invalidating
the cache.

[1]- https://github.com/odoo/odoo/blob/d3482e32f7dbe273125de84f1bbc434ac3c9ffc3/addons/web/models/ir_http.py#L146

[2]-
https://github.com/odoo/odoo/blob/7db62d6d65bd57f6ed43ce52a820cf03df19efdd/odoo/addons/base/models/res_users.py#L927-L931

[3]-
https://github.com/odoo/odoo/blob/3173a5f993a3ffa3d3a14d29713142e5b6b314d9/odoo/addons/base/models/res_company.py#L343-L367

Sentry-6251348500

Forward-Port-Of: odoo/odoo#219044

Currently a below occurs or content is not receiving to odoo WhatsApp when the user uploads a large file (tried with > 35 MB).

Stack Trace:
```
MemoryError: null
  File "odoo/http.py", line 2383, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1913, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1976, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1943, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2187, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 227, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 757, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/controller/main.py", line 42, in webhookpost
    wa_account_id._process_messages(value)
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/models/whatsapp_account.py", line 206, in _process_messages
    datas = wa_api._get_whatsapp_document(messages[message_type]['id'])
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/tools/whatsapp_api.py", line 236, in _get_whatsapp_document
    file_response = self.__api_requests("GET", file_url, auth_type="bearer", endpoint_include=True)
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/tools/whatsapp_api.py", line 46, in __api_requests
    if 'error' in res.json():
  File "requests/models.py", line 971, in json
    return complexjson.loads(self.text, **kwargs)
  File "requests/models.py", line 928, in text
    encoding = self.apparent_encoding
  File "requests/models.py", line 793, in apparent_encoding
    return chardet.detect(self.content)["encoding"]
  File "__init__.py", line 49, in detect
    detector.feed(byte_str)
  File "chardet/universaldetector.py", line 274, in feed
    if prober.feed(byte_str) == ProbingState.FOUND_IT:
  File "chardet/charsetgroupprober.py", line 70, in feed
    state = prober.feed(byte_str)
  File "chardet/hebrewprober.py", line 240, in feed
    byte_str = self.filter_high_byte_only(byte_str)
  File "chardet/charsetprober.py", line 73, in filter_high_byte_only
    buf = re.sub(b"([\x00-\x7F])+", b" ", buf)
  File "__init__.py", line 186, in sub
    return _compile(pattern, flags).sub(repl, string, count)
```

At line [1], the code `'error' in res.json()` is used, which reads all the json content of `res`, but at times users upload large files, it will cause the above error because the `json()` tries to read all bytes from res, which is a very large amount to handle in memory.

This commit will fix the above issue by returning a response if the response
contains content_length more than 10 MB.

[1] - https://github.com/odoo/enterprise/blob/aca7ae2a7cf4aad5427a60d5cad60d08774357d0/whatsapp/tools/whatsapp_api.py#L46

sentry-5810101850

Forward-Port-Of: odoo/enterprise#70001