The aim of this commit is to make all the action triggered by clicking the "Run manually" button in the reconcile.model from view performed by Odoobot.

Motivation:
- information consistency: As this is just a button triggering a bunch of automated action, we don't want the user clicking on the button to be tagged in the chatter as performing ALL the side effect action. For example, if an invoice gets reconciled by the process, before this commit, the invoice would be marked as paid by the user that clicked the button. After this commit, it will be marked as performed by Odoobot.

- behavior consistency: The end of the method triggers a CRON that will perform this action again on the remaining statement line to process but in the background. This will use the Odoobot user instead of the user that clicked the button. For example, before this commit, an invoice auto-reconciled in the second run of the method will be marked as paid by Odoobot while the invoices autoreconciled in the first run were mark as paid by the user clicking the button.

task-id: None (This was brought up during investigation on 4393854)

Description of the issue
========================

The initial issue was, when tracked product lines are grouped by product in batch ("Group batch lines" parameter checked in the picking type config), the sublines weren't displayed.
This issue was caused by the way we choose to display or not sublines. For a tracked product, we don't display them if reserved lot/serial is hidden (picking type config) and if there is no qty done.
That said, that didn't take in consideration the grouping by product where lines for different pickings are grouped together.
In this case, it's better to show the qty demand anyway to know how many quantity needs to be processed for each picking.

Once this issue is fixed, a second issue appears.
Imagine you have this following case:
- 1 line for lot product (0/4 qty) for receipt 1;
- 1 line for lot product (0/4 qty) for receipt 2.
- In batch, these lines are grouped because they share the same product.

Now, let's say we do the following process:
1. Scan the lot product -> The grouped line is selected;
2. Scan lot01 two times -> receipt 1 line is now 2/4 qty with lot01;
3. Scan lot02 -> receipt 2 line is now 1/4 with lot02.

The point 3. where is the issue happens. Usually, when we scan a lot, we check if the line is completed or not by checking its parent line's quantity. Here, the parent line is the batch grouped line and should not work exactly like that, because by checking this line as the parent of every sublines means we can't know if a particular picking need is fulfilled or not.

How to reproduce
================

- Inventory > Configuration > Operations Types > Barcode App:
  - Uncheck "Show reserved lot/SN";
  - Check "Group batch lines".
- Create two receipts for the same tracked by lot product;
- Create a batch for this receipt;
- Open the batch in the Barcode app -> You can see there is a line for   this product with the total quantity but when clicking on the button   to display sublines, the sublines are not shown.

Fix
===

For the first issue, we simply added a condition for `stock.picking.batch` to adapt to this case.

For the second issue, the group by tracked product inside a single picking and the group by product inside a batch are not the same and use a different key.
The first kind of group uses the key `parentLine` and the second one use the key `batchParentLine`. When we want the parent line of a subline, we will always refer to the `parentLine`. But in the interface, if this parent line is itself inside a `batchParentLine`, the `parentLine` won't be displayed, only the batch parent line.
That way, the user still has all lines for a same product grouped together under a single parent line, but to know if a need if fulfilled,
we still check on the parent line limited to a single picking.

[opw-4291149](https://www.odoo.com/odoo/project/49/tasks/4291149)

Forward-Port-Of: odoo/enterprise#79716
Forward-Port-Of: odoo/enterprise#79516

### Steps to reproduce:

- Enable "Multi-Steps Routes" in the settings
- Inventory > Configuration > Warehouse Management > Warehouses
- Put your warehouse in manufacturing in 2 steps
- Create an MO for a product and add an operation (no need of component)
- Confirm the MO and go to your operation in the shopfloor
- Click on the 3 dots > Add component > add any component
#### >  Back to the MO: No transfer was created from stock to pre-prod

### Cause of the issue:

When you add component from the shopfloor, you will trigger a call of the `add_product` method to create and confirm the raw move associated to the MO:
https://github.com/odoo/enterprise/blob/2e2efe8421b2f85950e50ff102cdabf98d2d91ab/mrp_workorder/wizard/additional_product.py#L36-L37 However, if the `procure_method`` of this move is not set to mto/mtso it will not trigger other rules in order to generate the other transfers

### Note:

A priori, the issue should not be reproducible in 18.0+ as this part of the code was refactored and the issue was fixed by 235047b68e6a24a14e32b94b1d4a15a580dc5ad2

opw-4236272

Forward-Port-Of: odoo/enterprise#80853
Forward-Port-Of: odoo/enterprise#74178

Steps to reproduce:

1. Install l10n_ar_edi
2. Use an Argentinian company
3. Go to the "Argentinean Localization" section of the settings
4. Make sure "Private Key" and "Certificate" are empty. Save.
5. Click on "Generate Request".
6. A key has been created but looks like it's not set on the company.

---

Description of the issue this commit addresses:

When generating a certificate request without selecting a private key to generate the certificate request with, a private key is generated by the system but in the settings windows, the field remains empty.

Also, later, after retrieving the certificate from the official platform and trying to insert it in the database, it is required to link it with the private key that was used for its generation but since all automatically generated keys share the same name, this can be quite hard.

---

Desired behavior after this commit is merged:

When using the "Generate Request" button with no private key selected, the Private Key fields is populated with the key that was created for the generation of the request.

Also, the names of the automatically generated keys use the current time for differenciation purposes.

---

Note on the fix:

The error happened because when using the Generate Request button, the key is created by a method called via another request so virtually, the assignment happens in another window. To fix that issue, the key has to be created and assigned before making any other request.

---

task-4393259

Forward-Port-Of: odoo/enterprise#79253

### Issue:

The barcode relies heavily on the data fetched in its LazyCache to work properly (in order to avoid rpc call's each time records data's are needed). However, some of these data's are loaded using search methods that ignore archived records by default. This leads to the creation of a cache that do not contains records that are expected to be there and hence will lead to tracebacks.

### Steps to reproduce:

- In the settings enable "Multi-Step Routes"
- Inventory > Configuration > Warehouse Management > Locations
- Create a new location WH/Stock/Love and a children location WH/Stock/Love/Layer
- Create and confirm an internal transfer from WH/Stock to WH/Stock/Love for 1 unit of any storable product in stock
- Change the location dest of the move line to WH/Stock/Love/Layer.
- Archive the location WH/Stock/Love
- Open your internal transfer in the barcode App.
#### > Traceback: An error occured in the owl lifecycle... Record stock.location with id=... doesn't exist in the cache, it should return by the server at LazyBarcodeCache.getRecord.

### Cause of the issue:

When entering the barcode man component, a call of the `get_barcode_data` is launched to fetch and populate the barcode data's and data are added to the barcode lazy cache in order to retreive record values without additional rpc calls:
https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/static/src/components/main.js#L76-L93 https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/static/src/models/barcode_model.js#L32-L34 For instance, when redering the picking template, the location dest id will be retreived from the cache:
https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/static/src/components/line.js#L7-L9 https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/static/src/models/barcode_picking_model.js#L1077-L1079 The traceback occurs because the record was actually never added to the data's and hence never added to the cache because part of the `get_barcode_data` call is performed with searchs that ignore completely the archived records (unless the 'active_test' key is in the context): https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/models/stock_picking.py#L102-L106

opw-4423110

Forward-Port-Of: odoo/enterprise#79686
Forward-Port-Of: odoo/enterprise#78297