There are several issues with the company of the folders and the
field `documents_spreadsheet_folder_id` of a company.

To reproduce the issue 01:
1. Create a second company
2. Documents > Configuration > Workspaces, edit "Spreadsheet":
   - Set a company

Step 01, `documents_spreadsheet_folder_id` of the second company is
set to "Spreadsheet" folder thanks to a default value on the field.
But, looking at the DB after the second step, there is an error: both
companies still have the folder "Spreadsheet" defined on
`documents_spreadsheet_folder_id`, but this folder is now specific to
one company. Step 2 should not be possible, a constraint is missing.

To reproduce the issue 02:
1. Repeat above steps 1-2
2. Create a third company

Looking at the DB, there is also an error with the third company: the
default value has been used for it, even though the folder is now
company-specific and can't be used anymore. The default value should
be improved to handle this situation.

Also, it should not be possible to use such record on the field.
Since there is already the attribute `check_company=True` on
`documents_spreadsheet_folder_id`, we could therefore add the attribute
`_check_company_auto` on the model and take advantage of the ORM:
https://github.com/odoo/odoo/blob/f323896028114acb36848b605732797b67fd7da4/odoo/models.py#L614-L618
However, this change would be too invasive on stable, hence the ORM
constraint as alternative.

OPW-4281530

### Steps to reproduce:
- In Accounting Dashboard, click on "import file" in the Bank kanban box
- Select a CSV file with two missing values on a line, for example:
```
Transaction Type,Bank Reference,Narrative,Debit Amount,Credit Amount
TRANSFER,bank_ref_1,bank_statement_line_1,,1000
TRANSFER,,bank_statement_line_2,,3500
```
(missing `bank_ref_2`)
- Complete the Odoo fields: Transaction Type, Reference, Label, Debit, Credit
- Import
- Go in Accounting Dashboard > Bank Reconciliation and select the list view
- `bank_statement_line_2` appears in Reference instead of Label

### Cause:
In `_parse_import_data` some line values are added and some are expected to be removed. The values expected to be removed are stored by index but they are removed by value. In this case the index supposed to be removed is 3 but its value is empty like index 1. On the line `line.remove(line[index])` the first occurrence is removed, so index 1 is removed instead of 3.

### Solution:
Use `del` to remove by index.

opw-4319464

Forward-Port-Of: odoo/enterprise#74512

The query in `_get_invoice_matching_so_candidates` will frequently plan a Seq Scan because of the low selectivity of the conditions. And when it does not, the number of rows returned by the CTE is expected to high. Because of that, filtering the resulting rows by a sequence of `OR` conditions can quickly become slow.

In this commit, the `OR` conditions are replaced by `LIKE(ANY(ARRAY[]))` conditions. That way the CTE is only referenced once in the conditions and applying the filter on each row is way faster. We also discarded duplicated `text_tokens` to reduce the size of the `ARRAY`.

The reason why using a `LIKE(ANY(ARRAY[]))` is faster is because postgres inlines the CTE in the outer query. This means that it performs a Seq Scan on sale.order and injects the CTE definition of sub.name inside the `WHERE` conditions of the outer query, along with injecting the `WHERE` conditions of the CTE.

So, the regex functions are distributed among the `OR` conditions. I.e. every `OR` condition left operand will contain the regex functions. As those have to be executed for every `OR` condition, this quickly becomes slow.

We can explicitely materialize the CTE to avoid that. This makes postgres evaluate the regex functions only once. But it will still have lots of `OR` conditions to check along with running pattern matching for each one of them.

`LIKE(ANY(ARRAY[]))` avoids this issue. The CTE is still inlined but since we now only have a single condition, the regex functions are only evaluated once and pattern matched once against an array of options. This makes the whole query faster and scale better.

#### speedup

Customer database with 808341 sale.orders. Query timing when increasing the number of text tokens.

| Number of tokens | Before PR | After PR |
|:-------------------:|:----------:|:--------:|
|        2         |     7s    |    1.3s  |
|        5         |     10s   |    1.3s  |
|        10        |     18s   |    1.4s  |
|        20        |     33s   |    1.55s |

opw-4329067
opw-4316765