In the case that an offer link is compromised, the access token needs to be changed to invalidate the old one. Right now it has to be done manually. This commit removes the ability to edit access tokens manually and instead generates a new access token whenever an offer email is sent.

The reason why the access token is set in the "MailComposeMessage" class instead of directly inside the "HrContractSalaryOffer" class is that the "Send by Email" button on the offer form doesn't directly send the email, it instead opens a dialogue to edit it before sending. In this dialogue, the user can just discard the email. If the access token was set when the dialogue was opened, discarding the email would change the access token of the offer without sending the new link. Instead of this the access token is updated right before sending the offer email.

The reason why some tours were modified is that since the access token
is tracked, changing it will produce a new message in the chatter, the
problem with this is that those tours have the assumption that the salary
configurator link will be in the first message in the chatter which is
no longer true as it is the second message now.

Task-ID: 5172914

When writing on reconcile models, the ORM fetches all the unreconciled bank.statement.lines then calls filtered on
`unreconciled_statement_lines.line_ids`. In databases with a lot of unreconciled statement lines scattered across multiple models, this `filtered` can be heavy, both in memory (fetching all the amls fields) and in time.

This commit fixes this by using a search to prefilter the amls using the reconcile models in self. Then we filter the result on `suspense_account_id`. This greatly reduces the number of lines loaded up in memory and speeds up writing on reconcile models.

### speedup

In a customer database with 484 042 statement.lines, 141 000 unreconciled statement.lines, 37 account.reconcile.model. Time to write on a reconcile_model.

| Nbr linked unreconciled lines| Before PR | After PR | 
|:----------------------------:|:---------:|:--------:|
|              702             |    40s    |   3s     |
|              2000            |    40s    |   4.47s  |
|              10000           |    40s    |   11.28s |

Since most of the slowness comes from the `filtered` call, the number of unreconciled statement lines linked to the reconcile.model being updated has no impact on the timing before this patch.

### memory

For the 702 unreconciled lines case, the memory consumption goes
 - 2.2 Gb -> 200Mb.

Forward-Port-Of: odoo/enterprise#115583

Steps to reproduce:
-------------------
1. Install account_winbooks_import, and switch to a Belgian company
2. Open Accounting > Configuration > Settings and click "Import", then click "Import WBK"
3. Upload a Winbooks zip whose chart of accounts uses 411000 typed as asset_current (Winbooks default for "VAT Recoverable")
4. Confirm the import

The import fails with:
"You must select a receivable account for 'Tax Receivable Account'."

Why the issue
-------------
In Winbooks, account 411000 is the V01 central account (tax receivable). In Odoo, 411000 comes from l10n_be (account "a411") with type "asset_current", not "asset_receivable". When the import wizard sets it on the existing tax groups via `manage_centralid` in import_wizard.py, the constraint `_constrains_payable_receivable_account` on account.tax.group rejects the write because the account is not "asset_receivable" + "non_trade".

This case was already handled in 20804db6d87: we bypassed the constraints on accounts coming from Winbooks, as those are imported in draft anw and the user finishes the configuration after.

However later, [2a38e771a826](https://github.com/odoo/odoo/commit/2a38e771a826) and ff5dee81080 removed the initial constraint and the code that bypassed it for account_winbooks_import.

Finally, [746a06fab485](https://github.com/odoo/odoo/commit/746a06fab485) added back a similar constraint "_constrains_payable_receivable_account" to fix a NL issue (same account used as both payable and receivable on a tax group). The Winbooks bypass however was not added back, so the original Winbooks issue appeared again.

The fix
-------
Add back the same bypass originally introduced in 20804db6d87.

opw-6092464

Forward-Port-Of: odoo/enterprise#115291

This commit fixes an error when retrying a rejected DIAN commercial event on manually created Vendor Bills.

This is a tricky error as it only happens when the vendor bill is manually created and the event is rejected (missing/incomplete info or servers down which is common).

To add more to this, this error can only be reproduced without demo mode as it forces the acceptance, forcing the need of valid testing or production DIAN credentials

How to reproduce it:
- Install l10n_co_dian module
- On CO company with all required DIAN configuration set
- Create a vendor bill manually with enough information to send to the DIAN but causing it to be rejected.
- Click on acknowledge receipt, it should be rejected
- Complete information to be accepted and again click on acknowledge receipt
- A traceback appear

Code expects the last document to be the most current one created when triggering commercial event, but this is not true when a rejected document exists since this is unlinked and cache invalidated causing the recordset to be invalidated and retrieved again by ORM with default order, so now the last document is the oldest one without an attachment causing the traceback

opw-6104541

Forward-Port-Of: odoo/enterprise#115914
Forward-Port-Of: odoo/enterprise#114758