For some editor options, interacting with them and clicking on the
editor save button while they were still focused caused a deadlock.

As an example:

- Drag & drop the "Dynamic Products" snippet
- Change the "Speed" option value and keep the input focused
- Click on the editor "Save" button
=> Deadlock

Funny enough: if you click slowly (mousedown -> wait -> mouseup), the
bug does not happen.

This was because this happened in that case:

1) Mousedown on the save button.
2) Focusout of the option's input -> the option's method is called.
3) The DOM is edited and the public widgets are restarted, which is an
   async operation. The dynamic products widget starts an RPC to render
   its content.
4) Mouseup (click) on the save button.
5) The editor immediately asks to destroy public widgets, this is a
   synchronous operation.
6) The rpc made at (3) finishes... but the result never reaches the
   widget as the ajax service does not let it be done for destroyed
   widgets (and the widget was destroyed at (5)).
7) The editor starts saving the content.

   => The editor gets stuck because before saving the content it waits
      for the general mutex of the editor to be unlocked... which is
      never the case because it is waiting for (3) to finish but never
      is marked as finished because the rpc is ignored at (6).

The problem actually is step (5) which should not happen. Indeed
destroying the public widgets is already done by another portion of
code at the appropriate time during the editor panel 'cleanForSave'.
That part was indeed indirectly and recently fixed by [1], ensuring
destroying widgets is only started when the general mutex is already
unlocked.

So, currently, the public widgets are destroyed two times: one too soon
which happens to work by chance most of the time and one at the proper
time (but which did nothing since a while because widgets were already
destroyed). This too-soon step (5) exists since [2] and was apparently
added alongside the existing mechanism for no apparent reason. It was
actually already done in 13.0, but as the editor panel was totally
different at the time, with no mutex ensuring the order of operations,
there should not be any problem having a random double widget destroy.
If a bug actually is reported, this could be backported.

This commit disables the public widget destruction made at step (5)
with a minimal stable diff.

[1]: https://github.com/odoo/odoo/commit/508332963202090bace0a3c877574132063c29a6
[2]: https://github.com/odoo/odoo/commit/f296992317e96562c66bd7ad59a5080d6c551ed5

Related to opw-2767903

Forward-Port-Of: odoo/odoo#92000
Forward-Port-Of: odoo/odoo#91791

#### The issue
In the invoice cancellation request, the <ReferenceDate> field should be the related invoice’s issue date. 

At the moment, it is set to the issue date of the cancellation request.

This causes Digiflow (the OSE) to return an error in the cancellation CDR, like this:
```
<cbc:ResponseCode listAgencyName="PE:SUNAT">2375</cbc:ResponseCode>
<cbc:Description>Fecha de emision del comprobante no coincide con la fecha de emision consignada en la comunicación
Detalle: ' ticket: 20210000000000193100584 error: Doc:[[1-FFRE-1],] fechaDoc: 2021-12-09 fechaRepo:2021-12-13 '</cbc:Description>
```

#### The fix
Set the ReferenceDate field to the related invoice’s issue date. 

#### How to test it
1. Create a fresh v14 db with l10n_pe_edi: `odoo-bin -d testing-pe-v14 -i l10n_pe_edi`

2. In both https://github.com/odoo/enterprise/blob/14.0/l10n_pe_edi/tests/test_edi_iap.py
and https://github.com/odoo/enterprise/blob/14.0/l10n_pe_edi/tests/test_edi_digiflow.py create a new UT from this gist: https://gist.github.com/antoine162/2af12b855434245cfc1295b7e6115d39
(I have written this as a gist rather than as a new UT because this is quite a corner case. But, if needed, I can make a UT out of this.)

3. Run the new UTs:
`odoo-bin -d testing-pe-v14 --test-tags='*.test_reproduce_error_fecha_no_coincida' --st` 

4. Without this fix the UTs should fail, after this fix they should pass.

#### Related support ticket

opw-2725105

Forward-Port-Of: odoo/enterprise#27561