## Summary

1. `--test-tags ".test_js[mail > widgets]"` will start all test_js starting with "mail > widgets"
2. `--test-tags "/web,-.test_js[Components > CheckBox]"` will start all web test, but skip Components > CheckBox qunit
3. ` --test-tags ".test_js[utils,-utils > Hooks,-utils > Patch]"` start all test_js utils tests except the Hooks and Patch ones
4. `--test-tags "-.test_js[Components > CheckBox]"` will start **all** tests, but skip Components > CheckBox qunit

## Motivation

Tags are used by runbot to *disable* randomly failing tests without the need to commit changes.
They can precisely target a python test method, class or module.

They can also be used by developer to run a *specific* test.

The problem is that the qunit is a special case, a js test suite inside the test_suite. It is only possible to disable all of them, or none of them.
Adding the possibility to enable/disable some of them was requested for a long time.

 ## Using test tags

The solution to use test-tags as multiple pros:
    - avoid a new command line argument
    - runbot already manages test-tags for errors meaning that this solution would imply minimal changes on this side
    - passing arguments to a specific tests, without regard of the qunit needs looks like a decent solution. This is a generic solution that could lead to other posibilities (profiling, test mode, ...)

Test tags are not aware of the purpose of the parameters, they will only be passed to the test. The tests has the responsibility to parse them.

 ## Chosen syntax and behavior

The main need is to be enable/disable some qunit. This means that we may want to support having parameters using comma `,` Unfortunately this may conflict with comma used to split tags if the syntax is not well defined.

The main idea to solve this issue was that it would be intuitive to give parameters as a function call would, between parentheses.
The opening and closing of the parentheses would allow to identify if a comma is part of the parameters or a tag separator. But using parenthesis is not a good idea in a command line since it could be interpreted by the shell.

The chosen alternative was to use `[]` to have a opening and closing symbol. Depending on how the parameters are interpreted, it can also be quite intuitive to understand: we select a specific element.
`.test_js[mail,stock]`

to run only js tests concerning mail and stock.
The idea to disable some qunit would be to specify a negative filter as for tags:

`.test_js[-some_module]`

Multiple matching tags may be given, in this case all parameters are given to the test. This is why test_parameters are a list of strings.

`.test_js[-m1,-m2],.test_js[-m3]` will be given to the test as `['-m1,-m2', '-m3']`

 ## Splitting the tags

The idea to support nested [] in params was considered but this would complexify a lot the parsing
`.test_method[filters=[mail,crm],failfast=0]`
This is NOT supported even if it could be. 

Parsing such tags would need a more complex parser (to split the , )
The final decision was made to keep it simple for now since it wouldn't be a problem to add this in the future if needed.

## Negating a parametric tag

A test tag can be negated to disable a test `-.test_js` (no op if test_js was not expected to run)
The question is, what is the expected behaviour of `-.test_js[mail]`.

### 1. Forbid this form
Simple solution, consider it as disabling a test, so passing the parameters would be usellesss and we should just don't allow that. But forbidding this form may force to make some complex development in runbot, since the current logic to disable a test is to add a '-' in front of the tag extected to run the test. 

### 2. Transform it to negate the parameter
It could be as simple as transforming `-.test_js[mail]` to `.test_js[-(mail)]`, or to manage the case when we could have already negated arguments (and multiple ones), tansform it to `.test_js[-mail-]`
The only cons of this solution is that adding the tag -.test_js[mail] would actually enable the test_js even if it is not the case, and be more equivalent to `.test_js,.test_js[-mail]`

### 3. Consider them apart: negated but not including. 
With this last solution, it is not possible to translate it as a tag, it would mean `.test_js[-mail]` if test_js is already enabled. This is whats looks to be the most robust solution. Adding a negated test-tag should not enable a test that wouldn't if not present

### 4. Always considered as parameters
`.test_js[mail]` would not enable test_js, but pass mail as parameter to test_js if another test enables it.
This means that to start the mail js test, we would use --test-tags .test_js,.test_js[mail]
This could make sence but would be less practical.

Since the main goal  is to be able to disable a specific qunit from the runbot, 2, 3 and 4 could work in most cases
but 2 could be problematic in edge cases, and for odoosh were we may want to use autotags but only enable test from one module. /my_module,.test_js[-some_test] would enable the test_js.
3 and 4 are equivalent for negation, but the automatic generation of config wouldn't work with 4. 

The current chosen solution is 3 since it looks to be the more practical.

Forward-Port-Of: odoo/odoo#200413

Reduce the memory footprint and slightly improve the performance of export, especially when we traverse multiple levels of relational fields.

We replace the https://github.com/odoo/odoo/pull/22494 solution because it is only works at the top level of the
export, to avoid invalidating records that may be used by the next iteration, and because the cache memory footprint of the cache has been reduced in recent years anyway. Instead, we explicitly read the only asked fields recursively.

Memory/Performance changes:

For exporting 10K of stock.picking (Transfers) with basic fields of the list view:
```
Before: 25 Mb of memory peak - 31 SQL requests, +- 55 ms of queries, +- 2440 ms of Python
After : 29 Mb of memory peak - 31 SQL requests, +- 45 ms of queries, +- 2402 ms of Python
```


For exporting 10K of stock.picking (Transfers) with their stock moves (30K) and their stock move line (4K):
```
Before: 191 Mb of memory peak - 162 SQL requests, +- 455 ms of queries, +- 7050 ms of Python
After : 140 Mb of memory peak - 129 SQL requests, +- 315 ms of queries, +- 6930 ms of Python
```

Forward-Port-Of: odoo/odoo#199218

Steps to reproduce the issue:

1. Activate the Odoo Mexican Localization Reports module
2. In a Mexican company, create a new Account with 1 as code
3. Go to Trial Balance and download COA SAT (XML)
5. In the General Settings with developer mode active, Download XSD files
6. Go to Trial Balance and download COA SAT (XML) again
7. You get a UserError with an unclear message

Explanation:

The Mexican Chart of Accounts have clear rules regarding `account.account.code`. The only way to verify those accounts is through the XSD files check, but they are not automatically downloaded and the error received with those files downloaded is not user friendly.

Fix reasoning:

Instead of regulating the code when downloading the XML. We'll add warnings on the Chart of Accounts to notify the user when a code is incorrect. To make the report error clearer to the user, we added a RedirectWarning that displays the accounts with faulty codes before generating the xml.

opw-4287338

Forward-Port-Of: odoo/enterprise#73943