[16.0] account_asset_batch_compute: Assets compute jobs considered "Done" despite asset move creation having failed

[Honeyxilia]

Module

account_asset_batch_compute, in concordance with account_asset_management

Describe the bug

When using the account.asset.compute wizard, with batch_processing turned on, if the account.move creation of the related depreciations fails, the job can still end up as "Done", even though the create_move instruction on the depreciations lead to an error (ie, a concurrency error : SeralizationError)

This is due to the current implementation of _compute_entries of the account.asset model, which catches the exception and display its error message to the end users only after ending the computation, to not disrupt the computation of all depreciations.
(see account_asset_management/models/account_asset.py:L1229

However, this means that jobs created to batch compute the asset depreciations never catch this exception, and finish the job normally, even if the account.move creation failed, requiring the end user to restart the jobs, either manually or as a batch, to correctly compute all desired entries

To Reproduce

Affected versions: 16.0 (the only one I'm able to vouch for this error atm)

Steps to reproduce the behavior:

1. Create more than 300 open account.asset records.
2. Open the "Accounting" -> "Assets" -> "Compute assets" wizard
3. Set the "Date" field to a far enough date (one month or two away), and set the "Batch processing" check to True.
4. Press "Compute"
5. Wait a few seconds or minutes for all jobs to finish, and go to the "Job Queue" menu
6. Check compute_entries jobs and their results - some of them won't have returned ids for newly created account.move records, but only error messages.

Expected behavior
Batch asset computing jobs should fail if the depreciation.create_move raised an Exception, as to be able to restart automatically later.

[Honeyxilia]

Checking out the v18.0 version of the module, it seems that an in-between model ( account.asset.compute.batch ) is created, which computes the assets, without using queue_job, but checks the returns on _compute_entries to detect whether the batch as succeeded or failed.

It might be beneficial to implement a similar system, fitting queue_job in V16.0 - if we have the time, we might turn our attention over to this.

https://github.com/OCA/account-financial-tools/blob/18.0/account_asset_compute_batch/models/account_asset_compute_batch.py#L93