Before this commit, when the user enables the task dependencies feature globally, all basic projects (that is, non fsm ones) will get the feature. By doing that, the open tasks state will be recomputed to set `Waiting` state on tasks with blocking tasks linked to them. The problem is the compute method of the task state will also reset the state instead of keeping the one set on those open tasks when there is no blocking task linked.

This commit makes sure the compute method of task state field is no longer called when the task dependencies feature changes. Instead, a inverse method is added on allow_task_dependencies field on `project.project` model to correctly update the state of the tasks linked to the project in which the task dependencies feature changed.

Steps to reproduce the issue:
----------------------------

0. install project
1. Create a project
2. Create some tasks inside that project and changes the state to some tasks
3. Enable the task dependencies feature in `Project > Configuration > Settings` menu.
4. Go back to the tasks kanban view of that project.

Current Behavior:
----------------

The state of those tasks is reset to `In progress` (if those tasks did not have a state equals to `Done` or `Canceled`).

Expected Behavior:
-----------------

The state of those tasks should not be altered since no dependencies are added in those tasks yet.

task-4487922

**Current behavior:**
When receiving product after having billed it already, if: A) the product is valuated,
B) the purchase is in a foreign currency,
C) there is an underlying exchange diff between time of bill and receiption

then the exchange difference account move will occur in the regular exchange account.

**Expected behavior:**
It should be for the stock valuation account.

**Steps to reproduce:**
*with anglo saxon accounting enabled*
1. Create a real-time valuated product invoiced on ordered qty
2. Activate a foreign currency, set some exchange rate for today and tomorrow (unique)
3. Make a purchase for the product, invoice -> post
4. The next day, receive the product
5. Check the exchange journal to see the offending AMLs

**Cause of the issue:**
In this flow, when the receipt is validated, at this point: *from `_validate_accounting_entries()`*
https://github.com/odoo/odoo/blob/7e7c1abeead0d4ef19ec15d50808ab33a642d25e/addons/stock_account/models/account_move.py#L185 the SVL linkage is somewhat broken because the bill's SVL was generated before the receiption's.

It means the exchange diff reconciliation proceeds as "usual" (without the `stock_account` module impacting the process) so the regular journal and accounts are used to record the amounts.

**Fix:**
Add overrides for getting the relevant journal and account(s) inside `_prepare_exchange_difference_move_vals()` in order to prevent `real_time` valuated product moves from generating AMLs in the ordinary exchange account (instead, use the stock journal and stock valuation account resp.)

opw-4655669

Currently when a survey has more than 1 page of questions, creating questions from the last page, last line, will add the question at the correct page but all other questions created further from the 'same' wizard will be added at the end of page 1 (beginning of page 2).

Steps to reproduce:
-------------------
* Open any survey and duplicate any question to have more than 50 questions.
* Navigate to the second page
* Select **"Add a question"**
* Add a title and seleect **Save & new** (repeat a couple times)
* Close the wizard
> Observation: The first question is added at the end of the survey. The
rest is added at the beginning of page 2

Why the fix:
------------
Since this commit was introduced https://github.com/odoo/odoo/commit/b1d185624599b9e4a5457399a99525a04de9d9bb the survey is saved each time a question is added. Globally speaking, when a form containing a list is saved, the list is refreshed back to page 1.

In our case, when we select **'Add a question'**, the list in the background is on page 2 and the last line will be used for the sequence of the new question. When selecting **save & New**, we can see in the background that the list is refreshed back to page 1 and the last line of page 1 will now be used for the sequence. So technically the questions are added at the end of page 1, and because page 1 is already full, they show at the beginning of page 2.

Now we systematically add the questions at the end of the survey by loading the last page of the list renderer after each save.

opw-4352543

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/6ac8bb744 [REL] 17.0.57 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/3a6008071 [FIX] clipboard: avoid huge revisions when copy/paste CFs/DVs [Task: 4718522](https://www.odoo.com/odoo/2328/tasks/4718522)
https://github.com/odoo/o-spreadsheet/commit/b035f9486 [FIX] clipboard: huge revision on pasting borders [Task: 4718522](https://www.odoo.com/odoo/2328/tasks/4718522)
https://github.com/odoo/o-spreadsheet/commit/c220c442b [PERF] autofill: improve command dispatching [Task: 4718202](https://www.odoo.com/odoo/2328/tasks/4718202)
https://github.com/odoo/o-spreadsheet/commit/c484787e0 [REL] 17.0.56 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/c9cf612b8 [PERF] tokenize: faster space tokenize [Task: 4684215](https://www.odoo.com/odoo/2328/tasks/4684215)
https://github.com/odoo/o-spreadsheet/commit/3d554b1ba [REF] tokenize: extract new line tokenize [Task: 4684215](https://www.odoo.com/odoo/2328/tasks/4684215)

Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

Currently, when validating deliveries, if multiples attachments are posted in the same chatter message, the printing jobs do not complete.

Steps to reproduce:
-------------------
* Install fedex
* In operation types, select Delivery Orders then hardware
* In print on validation, enable Carrier Labels and Export Documents
* In the shipping methods, select fedex international
* Change Label format to ZPL11
* Connect the database to an iot box
* Set up the shipping labels to be send on zebra printer
* Set up commercial invoice (/invoice) to be sent to another printer
* Create a sale order, using fedex international as shipping
* Confirm the SO
* Select the delivery
* Validate the delivery
> Observation: Nothing prints, jobs are sent to CUPS bu not printing

Why the fix:
------------
https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_fedex_rest/models/delivery_fedex.py#L192-L196

As show, when sending the shipping, if the invoice is generated, it gets added to the attachements. The function `message_post` will post all attachments in the same chatter message.

In `delivery_iot` the `message_post` function is overridden to allow sending the printing jobs to the iot.

https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_iot/models/stock_picking.py#L33-L46

Here, `attachments_names` will both contain `Label` and `ShippingDoc`. Since we enter the first if condition, the report is related to the shipping labels. Then we send the data related to all attachments to the device linked to the shipping labels, aka the zebra printer. Since the other attachment is of type PDF, the zebraprinter does not know what to do with it and ends up printing nothing.

Since we can have multiple different attachment, the if/elseif condition does not make sense. By breaking it in two if, we can send both reports separately, while still keeping all attachments in the same chatter message.

opw-4546715

* quality_mrp, stock_barcode

### Steps to reproduce:

- Create a product FP with a bom:
    - 1 x comp
- Create a control check point per product for FP for the manufacturing operation type
- Go to the barcode app
- Scan the manufacturing operation type
- Scan FP and set the qty_producing
- Click quality check
#### > Traceback

### Cause of the issue:

By scanning the manufacturing operation in the barcode we create a "New" manufacturing order that does not have a set id yet. As such, the `resId` the barcode `MainComponent` is `false`. However, this "id" is used in the orm call of the `checkQuality`:
https://github.com/odoo/enterprise/blob/79f98e924d2f425535a7ac1919f96ff7ec4a34d8/stock_barcode_quality_control/static/src/components/main.js#L15-L19 As such, we launch a call of the `check_quality`:
https://github.com/odoo/enterprise/blob/79f98e924d2f425535a7ac1919f96ff7ec4a34d8/quality_mrp/models/mrp_production.py#L70-L72 that ends up raising an traceback since the `product_uom` is `False` on the "unexpected" record `mrp.production(False,)`.

### Fix:

Since we just saved the record and hence created the record prior to this call:
https://github.com/odoo/enterprise/blob/79f98e924d2f425535a7ac1919f96ff7ec4a34d8/stock_barcode_quality_control/static/src/components/main.js#L12-L15 we should rather rely on the new created id.

opw-4644128

### Issue:

It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point.

### Step to reproduce:

- Set up Sendcloud, for a belgian company
- Select bpost and dpd for delivery and returns while loading products
- On a private window buy a storable product on the webstore online and select a sendcloud pickup point as the delivery method.
- With an employee confirm the delivery order that was created
#### > A problem occured in the generation of the return label

### Cause of the issue:

The `to_service_point` parameter is used by sendcloud's API in order to generate parcels and is added here:
https://github.com/odoo/enterprise/blob/747482f34ca8210d89d81b3363ec5a8fc3a4ff6f/delivery_sendcloud/models/sendcloud_service.py#L109-L112 However, this parameter does not make sense in case of a return since the customer is allowed to return the product to the pickup point of its choice. In particular, sendcloud's API will fail to genrate the return parcel if it is expecting to link the label to a given pickup point.

#### Note:

Sendcloud also fails to generate the return label when the shipping provider is the same for the delivery and for the return, so that the `to_service_point` can just not be provided for return labels.

opw-4562040