Description
-----------
On a database where the user doesn't Secure their accounting entries regularly, it's possible over a long period to accumulate a lot of pending invoices that needs to be hashed.

This can lead to the processing of a large number of moves when opening the Secure Entries wizard, more specifically: 
```
-> `_compute_warnings`
    -> `_compute_hash_date`
        -> `_compute_max_hash_date`
            -> `_get_chains_to_hash`
```
While manipulating this large recordset, the ORM prefetcher will read *all* fields on the model upon the first cache miss, which usually are a lot, and some of them are quite large (label type fields).

This commit refactors the code to avoid any cache miss by fetching only what is necessary. This is achieved by:
- Use of a `_read_group` instead of 2 subsequent `groupby`
- Delegate `max` and `min` lookup to the database
- Explicitly fetch the fields that are going to be read
- Avoid the linear search into the associated statement lines for unreconciled moves
- Introduce a context key `chain_info_warnings` to skip the warnings computation of `_get_chain_info`, as it's unused for the context of `_compute_max_hash_date`.

Benchmark
---------
On a database with over 1.3M `account.move` that are pending hashing, opening the wizard for the Secure Entries took:

|              | Before* | After   | Improvement |
|--------------|---------|---------|-------------|
| Memory       | 6.8 GiB | 700 MiB | 9.9x        |
| Query Count  | 26.7k   | 18.5k   | 1.4x        |
| Timing SQL   | 41.2s   | 18s     | 2.3x        |
| Timing PY    | 7.29min | 14s     | 31.2x       |
| Timing Total | 7.98min | 32s     | 15x         |

\* - benchmark was taken with unlimited memory, the request takes more than 2 GiB -> OOM killed and never completes

Reference
---------
opw-5014345

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

Forward-Port-Of: odoo/odoo#224105