Currently, a traceback is occurring when the user clicks the `Done & Schedule Next` 
button without having the due date.

To reproduce this issue:
1) Install Sales
2) Open any sale order and in the chatter, schedule an activity
3) Remove the `Due date` and click the `Done & Schedule Next` button

Error:-
```
TypeError: unsupported operand type(s) for +: 'NoneType' and 'relativedelta'
```

This traceback is occurring because `date_deadline` is not a required field. So the user can remove it.

If there is no `date_deadline`, the context contains key with no value from the line below.

https://github.com/odoo/odoo/blob/da7f89d5683c0718644b5ca9fdf5adb86b54fb81/addons/mail/models/mail_activity.py#L510

But here we are only checking the presence of the key in the context; 
If yes, the base is calculated based on the context value(None in this case). 

https://github.com/odoo/odoo/blob/da7f89d5683c0718644b5ca9fdf5adb86b54fb81/addons/mail/models/mail_activity.py#L204-L208
This will lead to the above traceback.

sentry-6347875218

Forward-Port-Of: odoo/odoo#199915

Before this commit, when starting a reply-to in composer, changing thread and posting a new message resulted in posting the message in the original thread instead.

Steps to reproduce:
- open a conversation A in Discuss app
- click on "reply" on a message
- open another conversation B in Discuss app
- compose a message then send it => the message is posted in conversation A rather than B

This happens because when changing conversation, the reply-to mode of the composer is kept. This is the case because `messageToReplyTo` is a stateful component hook of the thread viewer such as the Discuss app. This is put there because it's shared to both the `Thread` and `Composer` components, respectively to show the message being replied (reduced opacity to all other messages) and for composer to contains the reply-to message.

The cancelling of the reply-to mode was only occurring when the user manually cancel it. Changing conversation was not considered as cancelling. This commit fixes this issue.

Task-4593206

Forward-Port-Of: odoo/odoo#198653

Versions
--------
- 17.0+

Enterprise PR: https://github.com/odoo/enterprise/pull/81461

Steps
-----
1. Have a internal user with only Sales: Own Documents access;
2. assign the user to a subscription;
3. as admin, create an invoice for the subscription;
4. assign yoursel as salesman on the invoice;
5. confirm the invoice;
6. log in as the other user;
7. try to create an invoice for the subscription assigned to you.

Issue
-----
Access error.

Cause
-----
Unlike the the other `_compute_amount_*` methods of sale.order, `_compute_amount_invoiced` isn't computed with `sudo`.

This isn't an issue when just using `sale`, as it's computed with only sale order fields, but if an override attempts to check `invoice_ids`, it will throw an error if it has an invoice you don't have access to.

Solution
--------
In `sale`:
- The bring the compute method in line with other `_compute_amount_*` methods, add `compute_sudo=True` to the `amount_invoiced` field.

In `sale_subscription`:
- Add a test to prevent regression.

opw-4554639

Forward-Port-Of: odoo/odoo#201768

**Steps to reproduce:**
- Install Accounting and l10n_it_edi_withholding
- Switch to an Italian company (e.g. IT Company)
- Import an electronic Italian invoice (XML) containing an element like:

```xml
<DettaglioLinee>
    <NumeroLinea>2</NumeroLinea>
    <Descrizione>Contributo ENASARCO</Descrizione>
    <PrezzoUnitario>0.00</PrezzoUnitario>
    <PrezzoTotale>0.00</PrezzoTotale>
    <AliquotaIVA>22.00</AliquotaIVA>
    <AltriDatiGestionali>
        <TipoDato>CASSA-PREV</TipoDato>
        <RiferimentoTesto>TC07 - ENASARCO</RiferimentoTesto>
        <RiferimentoNumero>10.03</RiferimentoNumero>
    </AltriDatiGestionali>
</DettaglioLinee>
```

**Issue:**
1) When the above ENASARCO element is present and its unit price is 0, we consider that the ENASARCO tax should be applied to each line. We try to retrieve the percentage of the ENASARCO tax used by computing it from the amount from <RiferimentoNumero> element and the untaxed amount of the invoice.
Then the ENASARCO tax is applied on all the current move lines. However, it is possible that all the move lines have not been imported yet and the tax will not be applied on all the lines.

2) If a ENASARCO tax has been set on a particular move line with a unit price of 0, the tax is applied to all the move lines, but it shouldn't.

3) When a global ENASARCO element is found in a move line, this move line is deleted, which can cause an error if the ENASARCO tax cannot be found in the database because a message is logged with the move line name.

**Solution:**
1-2. In "_l10n_it_edi_import_line" method, we had the ENASARCO tax to the current line by computing the tax rate with the unit price of the line if it is not 0.
Then, in "_l10n_it_edi_import_invoice" method, we parse the XML to check if there was a unique ENASARCO element with an amount and without unit price.
If it is the case, we considered the ENASARCO tax as global. Instead of using the untaxed amount of the invoice to compute the rate of the ENASARCO tax used, we should be able to retrieve the real taxable amount in a <DatiRiepilogo> element.

There should be an element like:

```xml
<DatiRiepilogo>
    <AliquotaIVA>22.00</AliquotaIVA>
    <ImponibileImporto>117.97</ImponibileImporto>
    <Imposta>25.95</Imposta>
    <EsigibilitaIVA>I</EsigibilitaIVA>
</DatiRiepilogo>
```
from which we sum all the "ImponibileImporto" values.

3) Only remove the line if the ENASARCO tax is global and can be found in the database.

Ref old fix: https://github.com/odoo/odoo/pull/197456

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4555966)
opw-4555966

Forward-Port-Of: odoo/odoo#200774

Versions
--------
- 17.0+

Community PR: https://github.com/odoo/odoo/pull/201768

Steps
-----
1. Have a internal user with only Sales: Own Documents access;
2. assign the user to a subscription;
3. as admin, create an invoice for the subscription;
4. assign yoursel as salesman on the invoice;
5. confirm the invoice;
6. log in as the other user;
7. try to create an invoice for the subscription assigned to you.

Issue
-----
Access error.

Cause
-----
Unlike the the other `_compute_amount_*` methods of sale.order, `_compute_amount_invoiced` isn't computed with `sudo`.

This isn't an issue when just using `sale`, as it's computed with only sale order fields, but if an override attempts to check `invoice_ids`, it will throw an error if it has an invoice you don't have access to.

Solution
--------
In `sale`:
- Bring the compute method in line with other `_compute_amount_*` methods, add `compute_sudo=True` to the `amount_invoiced` field.

In `sale_subscription`:
- Add a test to prevent regression.

opw-4554639

Forward-Port-Of: odoo/enterprise#81461