We enable the synchronization of document account by default, and we create automatically the journal synchronization configuration along with the corresponding folder and tag when a journal is created.

We also create all the synchronization configuration of the existing journal when documents_account is installed.

Notes:
- we do the configuration of the journal synchronization in sudo because the user creating the journal has not necessary access to document.
- we transfer the translation of the journal type to the folder name, but it only transfers the installed language so to benefit from it, languages must be activated before documents_account is installed.
- we also transfer the translation of the journal name to the documents tags. But as we can only add translations after the creation of the journal where the auto creation of the settings are performed, it will only benefit when installing documents_account after having activated multiple language and added translation to the journal names.

[IMP] documents_account: remove accounting sync option

The user can no longer disable the accounting synchronization with document when documents_account is installed.

Note: Following the change of _get_default_folder in account_reports.export.wizard where we just return the account_folder_id of the company, we set precompute to True for the field account_folder_id of company to ensure a folder is set by default. Note that the field is not required on the model but well in the settings view. test failing without that change: account_reports:TestAllReportsGeneration.test_generate_all_export_files

[IMP] documents{_account}: prevent document warning in the tests

In document._prepare_create_values, we emit a warning and set the owner to False when the owner of the document to be created is not active. Now that we have enabled the document account synchronization as soon as document_account is installed, we get that warning in lot of account test. To avoid those warning, we set upstream the owner to False when the owner is not active.

Co-authored by: Stephane Debauche <std@odoo.com>

[IMP] documents_account: disable documents sync during account test

To avoid a lot of test to fail or emit warning in account (not in documents_account) following the enabling of the account document synchronization by default, we disable the document account synchronization during the account test and re-enable it for documents account test.

We also modify the tests because they were expecting that no configurations for journal synchronization were set up which is no longer the case.

Task-4873102

In the stock module one of the bottleneck of the
`_compute_quantities` is the call to `product.update`. While this is not really an issue when the number of products is small, it becomes slow when this number grows above 100 000 products. This can happen when searching on one of the computed non-stored fields for instance.

In this case, the underlying issue is the unbatched call to `__setitem__` that calls `Float.convert_to_cache` that calls `get_digits` and `float_round`. These two methods are not that costly for small recordsets but can take a bit of time for larger ones. The solution proposed in this commit is to grouped the quantities_dict by values then call update on batches of product.products. This leads to a noticeable speedup, mostly for the > 100 000 records recordsets.

Another bottleneck appears when the mrp module is installed. When there's a lot of products, the calls to `mrp.bom.explode` can stack up and lead to slow execution. A solution for this is to memoize the exploded values of the boms. We can do that because this value is actually independent of the current product, as we are not using the first list returned by the `explode` method. This leads to a noticeable speedup, especially in database where there are a small number of boms for a large number of product.products.

speedup

Time to search for products with `free_qty` > 0.0. Database with mrp installed and kit boms. Most of the kit boms are for templates. 800 000 products in the db, 15 000 templates.

| Total number of products | Before PR | After PR  | 
|:------------------------:|:---------:|:---------:|
|           100            |    51ms   |   48ms    |
|          1000            |    220ms  |   200ms   |
|         10000            |    1.2s   |   900ms   |
|        100000            |    10s    |   5.77s   |
|        800000            |    15min  |   1min15s |

The customer database has 3 boms for templates that have more than 20 000 variants each. In this case, memoizing the explode gives a significant speedup. That's what happens in the 800 000 case above.


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