## [FIX] l10n_ar: prevent errors from deleted tax group

When users delete the tax group `tax_group_percepcion_ganancias` while using the Argentinian localization, it will an error when trying to send an electronic invoice or generate the VAT books, since it depends on this specific tax group.

There is no clearer way to identify this tax group than by its XML ID.

This commit does two things:
1. It prevents users from deleting this required tax group when the company is using the Argentinian localization.
2. If the tax group was already removed, it will show a useful error message when it can't be found and redirect the user to the settings where they can reload their chart template in order to reinstall the tax group.

[task-3853596](https://www.odoo.com/odoo/all-tasks/3853596)
[opw-3685073](https://www.odoo.com/odoo/all-tasks/3685073)

## [FIX] account: fallback on company data when loading chart template

Currently when loading a chart template for a company which is referencing some records by XML ID, we look for these records in the database. This could fail in some cases, like this:

- We have a company set up with a CoA and delete one of its default accounts in the company settings and replace it by another account.
- We try to create a branch company under the former one.

When trying to save the branch company, we try loading the chart template on it, setting also the default accounts. We look in the database for the right reference, but since the parent company deleted the original account, the process fails and the branch can't be created.

In this commit we provide a sensible fallback. If the record referenced in the chart template can't be found, we try looking what was already set on the company or its root. As such, we will be able to create the branch successfully and the user can always adapt the defaults later.

[task-3853596](https://www.odoo.com/odoo/all-tasks/3853596)
[opw-3677061](https://www.odoo.com/odoo/all-tasks/3677061)
[opw-3681481](https://www.odoo.com/odoo/all-tasks/3681481)
[opw-3681456](https://www.odoo.com/odoo/all-tasks/3681456)
[opw-3672507](https://www.odoo.com/odoo/all-tasks/3672507)
[opw-3669164](https://www.odoo.com/odoo/all-tasks/3669164)
[opw-3694606](https://www.odoo.com/odoo/all-tasks/3694606)
[opw-3705870](https://www.odoo.com/odoo/all-tasks/3705870)
[opw-3704826](https://www.odoo.com/odoo/all-tasks/3704826)

Forward-Port-Of: odoo/odoo#183609

**Current behavior:**
Creating an import file with enough blank rows to require import via batches will cause duplicate records from previous batches.

**Expected behavior:**
No duplicates.

**Steps to reproduce:**
*E.g., `-i contacts`*
1. Create a csv file with a partner record on row 1 (or 2 if using headers, just the name is enough for `res.partner`) and another record on row 2002 or higher

2. From contacts action button, select import records, upload the csv from step 1, import

3. See that the 2 records were imported 2x each

**Cause of the issue:**
When the `file_length` (literal number of lines) is big enough to require batches, but the actual number of rows with data is not, the upload mechanism will try to (in the case described here) upload 2 batches of records.

But because there isn't actually a full batch of records, the second batch will just be the same as the first (second batch starts from row 0 "bookmark", because all the data rows were processed in their entirety in the first batch).

**Fix:**
Make `file_length` returned by the server to client the length of the actual data rows parsed from the file, as opposed to the literal number of lines.

opw-4271105

Forward-Port-Of: odoo/odoo#185634