## Description
When calling `get_contact_info` searching with a number that starts with `0` will try to do a pattern match with an `=like` + prefix `%`. The problem is that there is only a `btree` index defined to support the searching that happens via `phone_mobile_search`, but a `btree` index cannot be used with pattern matching `%`/`_` at the *beginning* of the search term. Therefor Postgres will do a `Seq.Scan`, since it's the only criteria there is for this domain.

## Solution
To support pattern searching starting with a wildcard, it's required that there is a defined `gin` index with the proper expression (`regexp_replace` support). Since this is the only instance where such searching is needed, adding a whole index for it is overkill. An alternative solution is to do exact matches for all possible country code we have. This is a *sane* operation, as the number of countries is small and fixed. We avoid the `Seq.Scan` by hitting the defined `btree` index. Sadly the `phone_mobile_search` field doesn't implement the `in/not in` operator, so we are forced to use `OR` for each domain leaf, as implementing the `in/not in` ops on the search field is not feasible in a small diff for a stable patch. The where clause from the generated query from the domain will be a disjunction of a bunch of `OR FALSE` or `OR res_partner.id IN (<ids>)`. Thankfully, this is an SQL structure that Postgres can optimize out (removing the redundant `OR FALSE` clauses), reducing the query to a simple `id IN (...)`, which will hit the Pkey index. The only regression is the number of queries executed to resolve the domain of the search field, which +1 query count for each OR leaf of the domain. (would be avoided if the search field implemented the `in` ops).

## Benchmark
On a staging database with over 5M `res.partner`, the time taken for the resolution of the searchable field `phone_mobile_search` takes:

|         | Before  | After  |
|---------|---------|--------|
| Timings | 12.43 s | 270 ms |

## Reference
task-3942852