Issue:
------
Commit 749e0af3639d243f1d24e40f9c0d374c634eaf79 improves the performance of the `res.device` model in the case of a filtered search (for a given user or a given id).

However, when the search is not filtered (`SELECT * FROM res_device`), it takes a long time.
This scenario occurs when an administrator goes to the list view of this model.

Solution:
---------
For each row in the main `res_device_log` table, the subquery checks to see if a more recent (and unrevoked) `res_device_log` exists. If no similar log is found for a row in the second table then the row in the main table is considered to be the most recent.
The subquery therefore returns a boolean (`NOT EXISTS`) depending on whether or not a more recent log is present.
This boolean is assigned to a column called `is_latest_res_device_log`. Finally, we keep only the `res_device_log` in the main table which are not revoked and sort them according to `last_activity`.

This solution allows us to retain the behaviour we were looking for in the previous commit (mentioned above), i.e. to be able to use the indexes on the `user_id` and on the primary key.

In addition, the composite index is no longer necessary.

Appendices:
------------
For the query: `SELECT * FROM res_device`

Before:
```
Sort  (cost=641167.54..646433.53 rows=2106398 width=154) (actual time=24593.801..24909.190 rows=2355405 loops=1)
Sort Key: d.last_activity DESC
Sort Method: external merge  Disk: 347992kB
->  Merge Anti Join  (cost=1.11..419928.90 rows=2106398 width=154) (actual time=152.329..22591.230 rows=2355405 loops=1)
     Merge Cond: ((d.user_id = d2.user_id) AND ((d.session_identifier)::text = (d2.session_identifier)::text))
     Join Filter: ((NOT ((d2.platform)::text IS DISTINCT FROM (d.platform)::text)) AND (NOT ((d2.browser)::text IS DISTINCT FROM (d.browser)::text)) AND ((d2.last_activity > d.last_activity) OR ((d2.last_activity = d.last_activity) AND (d2.id > d.id))))
     Rows Removed by Join Filter: 64033675
     ->  Index Scan using res_device_log__composite_idx on res_device_log d  (cost=0.56..230724.16 rows=4674167 width=154) (actual time=1.367..8816.957 rows=4679105 loops=1)
     ->  Index Only Scan using res_device_log__composite_idx on res_device_log d2  (cost=0.56..142427.83 rows=4674167 width=73) (actual time=0.023..7622.788 rows=64033676 loops=1)
           Heap Fetches: 4281591
Planning Time: 1.008 ms

Execution Time: 25007.378 ms
```

After:
```
Index Scan Backward using res_device_log__last_activity_index on res_device_log d  (cost=0.43..195099.12 rows=4674167 width=154) (actual time=2.286..2091.532 rows=4679105 loops=1)
Filter: (NOT revoked)
Rows Removed by Filter: 6018
Planning Time: 0.117 ms

Execution Time: 2231.288 ms
```

### Steps to reproduce the issue:

1. With studio, add a signature field to the Expense Form
2. Create a new expense with a signature
3. Receive the following error:

>       File "[...]/odoo/addons/hr_expense/models/hr_expense.py", line 459, in _compute_same_receipt_expense_ids
>         same_receipt_ids.update(expenses_groupby_checksum[attachment.checksum])
>     KeyError: <string of letters and numbers>

### Explanation:

When a Binary field is assigned a value.`ir.attachment` is automatically created and linked to said field through `res_field`. https://github.com/odoo/odoo/blob/9b440d5b07d9683d7f051baa98476b2977acba0f/odoo/fields.py#L2514-L2522 In the database, when retrieving attachments, those with `res_field` assigned are discarded from the query. https://github.com/odoo/odoo/blob/bfd7945d634bd4d46c4d62e93061581c6c5b09c1/odoo/addons/base/models/ir_attachment.py#L520-L526 During the creation of `hr.expense`, `attachment_ids` is assigned all attachments created and linked to it, in the cache, through `res_id`. https://github.com/odoo/odoo/blob/9b440d5b07d9683d7f051baa98476b2977acba0f/odoo/fields.py#L3290 Since saas-17.4, the compute method `_compute_same_receipt_expense_ids` has been added with a dependency on `attachment_ids`. If, during the creation, a Binary field has been assigned a value and `ir.attachment` created, the latter will still be linked to `attachment_ids` in the cache and found in the `filtered` method, while the `_read_group`, checking the database, will discard it due to `res_field` having a value. https://github.com/odoo/odoo/blob/6b8e07e36c6e6e283d21c2b5abd9a9dabf10fa4a/addons/hr_expense/models/hr_expense.py#L445-L454 Due to that difference between the cache and the database, an issue occurs when trying to retrieve the value from `ir.attachment`.

### Fix reasoning:

`attachment_ids` has a domain attribute, but it is not correctly assigned. The value should be a List instead of a String. https://github.com/odoo/odoo/blob/9b440d5b07d9683d7f051baa98476b2977acba0f/odoo/fields.py#L2991 While this specific domain is not necessary for One2Many fields since it is already covered by the override in `get_domain_list`. https://github.com/odoo/odoo/blob/9b440d5b07d9683d7f051baa98476b2977acba0f/odoo/fields.py#L4497-L4498 We will keep it to make sure the cache is invalidated and `attachment_ids` is retrieved from the database. https://github.com/odoo/odoo/blob/bde4952255987cd21ceaabdf13f0a271b6ab10fa/odoo/models.py#L6889-L6894

opw-4293803