Before, the operation types were could only be set on the Sale Order or on the Invoice level. This works for most cases but if a customer needs to invoice products by different operation types they can't.

This commit makes it possible to pick from the same list of values as on the parent orders/invoices as an "override" value for an specific lines that need a different operation type. This means that for any line that does not have an override set, the field of the parent model is used instead.

In addition the l10n_br_test_avatax_sale module was kept after the refactor of external_tax modules because the code of the module was no longer necessary but the test cases still had use. Later down the line, the l10n_br_avatax_sale module was created to account for CNAE, operation types, and other new features. 

As this module expands it makes sense to move the test code back to it instead of keeping a separate test module.

Upgrade PR: odoo/upgrade#7390

Task [link](https://www.odoo.com/odoo/project/967/tasks/4569548)
task-4569548

Before this commit, actions, and views were cached in RAM in their respective
services. This enhanced the system's performance when loading the same
actions/views. However,  the RAM cache was flushed on reload (or when the tab
was closed). Additionally,  it was not shared between tabs.

This commit introduces a new caching system, which will have two caches: a RAM
cache as before, and a new disk cache (using the IndexedDB API [1]). To utilise
the new caching system, you can add a `cached: true` setting on the rpc, or a
`cached` property on the orm:

```js
this.orm.cached.call(....
```
```js
rpc(url, params, { cached: true });
```

The caching system will behave as follows:
- If a value is found in the RAM cache, it will be used (as it was before).
- Otherwise: If a value is found in the disk cache, is that value that will be
    used. The key difference is that, the RPC will also be performed, and the
    caches will be updated.

This disk cache will be shared between tabs, and it will not be flushed during
a reload (or when closing of the browser). Please note that a hard reload
(Ctrl + F5) will flush all the caches. Another advantage of this new cached
system is that it is developed on a central place, and the developers will not
need to re-develop their own cache system as it's the case now.

This new caching system will not lower the quantities of RPC performed, but it
will not wait until the return of the RPC to continue the rendering, which will
speed up the rendering of already visited pages.

task-id 4251018

[1]: https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API

Description
-----------
When clicking the sharing button on a knowledge article, the system retrieves all members linked to the article. This includes members directly tied to the article or inherited through parent articles ( stopping at the first desynchronized article). In databases where articles have numerous associated members, the
`_get_article_member_permissions` method suffers from severe performance issues. It retrieves *all* articles and their associated members, collects all parent articles in the hierarchy, and only then applies grouping and filtering based on the `id` of `self`. This process includes a `LEFT OUTER JOIN` on related tables to fetch specific `fields` passed as arguments, resulting in an O(n^2) complexity on large tables such as `res.partner` and `knowledge.article.member` (the latter being a Many2many relationship that typically contains a high volume of rows).

This patch improves performance by shifting the grouping and filtering logic to the start of the process, effectively injecting all preconditions at the base of the recursion. This reduces the hierarchy of articles and memberships to explore. Additionally, the computation of inherited permissions—sourced from the "closest" ancestor article—is now handled at the SQL level instead of Python. This eliminates unnecessary rows in the process, avoiding unnecessary work in the business logic afterward.

Benchmark
---------
On a client's database with around 600 articles, 5k partners and 15k knowledge.article.member in total, for a specific article which has a total of 1.7k members (direct and inherited):

| Request                        | Before  | After | Speed-up  |
|--------------------------------|---------|-------|-----------|
| `_get_article_permission_data` | 4.7+min | 150ms | **1880x** |

Reference
---------
opw-4603551

Forward-Port-Of: odoo/enterprise#81264

Currently, an exception is generated when a user tries to save a product record without a barcode, whether it is a newly created record or an existing one.

Steps to reproduce:

1. Install the Inventory module.
2. Go to Inventory settings.
3. Set Barcode Nomenclature to Default GS1 Nomenclature.
4.  Go to Inventory -> Products, create a product with a barcode, and save it.
5. Edit the same product, remove the barcode, and save it again.
6. An error occurs.

Error: `StopIteration`

This issue [1] occurs because when a user tries to save the record without a barcode, the value is false, and an false value is not iterable.

[1] - https://github.com/odoo/odoo/blob/9eb6c16cd7d4fe9364d043e2af96876bf82a44d4/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L163

This fix resolves an issue where GS1 preprocessing was always applied when checking for duplicate product barcodes. By introducing the skip_preprocess_gs1 context flag, the GS1 preprocessing step is now bypassed when verifying barcode uniqueness.

Related Community PR:- https://github.com/odoo/odoo/pull/196438

sentry-6267124218

Forward-Port-Of: odoo/enterprise#80544