This PR changes the sales and purchase taxes for Cyprus when selling/purchasing within the EU. 
- All sales taxes changed to 0% when selling to country within the EU. 
- All purchase taxes changed to 19% when buying from country within the EU. However, a second tax repartition line is added at -100% of the tax. The tax is effectively applied and deducted at the same time. 
- Redundant taxes were removed like zero rate taxes and taxes with reverse charge.

task-4488340

Current behavior before PR:
- When selling to other EU countries, a 19% sales tax is added to goods and services.
- When buying with other EU countries, a 0% VAT tax is added to goods and a 19% VAT tax is added to services.

Desired behavior after PR is merged:
- When selling to other EU countries, a 0% sales tax is added to goods and services.
- When buying with other EU countries, a 19% VAT tax is added to goods and services, and a second tax repartition line is added at -100% of the tax effectively making it 0.

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

The `s_numbers_charts` snippet had two main issues:
- The progress bar within `s_numbers_charts` visually appeared as 45% on
  initial rendering, despite its actual configured value being 25%. This
was due to a mismatch between its `aria-valuenow` attribute and its
style `width` property. The display would correct itself when the user
manually changed the value.

- A crash would occur when attempting to select the "Label" option after
  dropping the `s_numbers_charts` snippet. This happened because
`s_progress_bar_text` was forgotten during the initial implementation of
`s_numbers_charts` [1].

This commit addresses these problems by:
- Adding the missing `s_progress_bar_text` to the `s_numbers_charts` template.
- Including `s_progress_bar_text` in `_computeSnippetTemplates` to
  ensure that existing databases also receive this fix, as snippets are
stored in the database.
- Adding a check in the `progress` option to prevent the aforementioned crash.

Steps to reproduce the crash:
- Drop the `s_numbers_charts` snippet.
- Click on a progress bar within the snippet.
- Select the option `Label`.
- Hover over "Hide" without any other prior interactions.
- A crash will occur.

[1]: https://github.com/odoo/odoo/commit/6c94fd66c1db75d74588ce670fb6cf1e960cf8bd

# Context :

By design the CRON “Mail Marketing: Process queue” handling the email marketing campaigns is expected to time out for large mailing list. By default it tries to generate and commit batches (default 50) of `mail.mail`
 records while working through the total list of remaining recipients.
See `_action_send_mail_mass_mail` method https://github.com/odoo/odoo/blob/8ff5079b1f5c4df23d56b7f170151408fa7f6f8c/addons/mail/wizard/mail_compose_message.py#L752 In practice, for large mailing lists this will take longer than 15 mins (the default real time limit for CRON jobs) and thus implicitly we expect the worker to time out, re-initiate and continue where it left off.

But since Odoo 18, the new refactor of `ir.cron` tries to penalize jobs that time out too often (>3) and don’t report at least a partial progress
(`_notify_progress()`).
See https://github.com/odoo/odoo/blob/8ff5079b1f5c4df23d56b7f170151408fa7f6f8c/odoo/addons/base/models/ir_cron.py#L361C1-L367C39

While `_process_mass_mailing_queue` does use the notify progress method (https://github.com/odoo/odoo/blob/8ff5079b1f5c4df23d56b7f170151408fa7f6f8c/addons/mass_mailing/models/mailing.py#L1167),
 it does so at a higher level or granularity (the `mailing.mailing` records in queue).
But it will never called as long as the CRON keeps timing out while
 processing the mails for the remaining recipients (that get committed by batches).
Which leads to the CRON being flagged as timing out to many times, and
 the `nextcall` date of the job being incremented by it’s default value of 1 day.

So in practice:
- mail marketing starts processing
- will time out 3 times after 15 mins (default real time)
- new system kicks in and increments the next execution date + 1 day
- cron does not run until next day (so no new mail batches created) → artificially low sending rate of the campaign even-though everything is in order

# Proposed solution:

One could argue that the real unit of work is the committed mail records
 done in `_action_send_mail_mass_mail`. So we count the processed
 recipients/mails and call _notify_progress()` before the auto commit
 (which will be active when the method is called during the CRON).
This should ensure that the CRON will not be penalized for timing out too
 often as long as the recipients are defacto being processed by batches.

opw-4633353

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

Before this commit
------------------
if a user had a multi-company setup with a different alias domain set for each company, a multi-company error could happen. It happens when sending a mail with attachment to an accounting journal alias.
The exact conditions required to enable the option to centralise all attachments in Documents for the journal in question.

steps to reproduce:
1. clean DB with documents_account installed
2. create a 2nd company "company 2"
3. create an alias domain for company 1 "alias.company1.com" and another alias domain for company 2 "alias.company2.com"
4. in documents, create a "finance" folder for company 1 (i.e. set the company_id field on the folder) and another folder for company 2
5. configure the settings for both companies so that all attachments are centralized in documents for accounting, in the respective folder for that company
6. create an alias for some journals in company 2 (e.g. vendor-bills@alias.company2.com)
7. send an email with attachment to that alias -> you will get a multi-company error

After this commit
------------------
Sending a mail with attachment to an accounting journal alias creates the account_move as expected. The attachment is parsed as expected.

opw-4727873
opw-4655559
opw-4746321
opw-4766895