## Description
In a large database with many `helpdesk.ticket` and `res.partner`, opening the form view of a ticket can take a lot of time. This is due of the smart button that computes and counts the number of 'related' tickets that are linked to the partner customer of the current ticket. By specifications, the related tickets should have either:
- same email as the current partner
- same phone as the current partner
- partners children of the current partner's commercial entity

## Analysis
- `_compute_partner_ticket_count` can take a bit of time, as first we are forced to loop-over the recordset so we can create a domain, that is dependant on the individual ticket's assigned customer. Therefor said loop cannot be converted to a `read_group`. This domain also is a disjunction (aka ORs) of multiple conditions, that all kinda overlap themselves, as usually phone and emails are unique per partner. This disjunction also prevent the eventual use of indexes, not that there are any currently on `partner_phone` and `partner_email`.
- `_compute_fsm_task_count` is taking more time than what it could be, because of a faulty domain. We are currently just checking that `helpdesk_ticket_id` is not empty, but that forces the database to do a full-table scan and filter out the unrelated `project.task`.

## Solution
- `_compute_partner_ticket_count`: Since the results of the disjunction has overlapping results, and one of the condition contains all the results from the other 2 conditions, the 2 redundant conditions can be removed. This allows us to add an index on `partner_id` to allow an index scan for fetching the tickets related to said partner. Usage of a narrow pre-fetch on 'stage_id' allows us to remove the context key `prefetch_fields=False`, which was put in place to prevent out-of-memory error in the past, but now can be added back with the new pre-fetcher, without aggressively prefetching many fields that are not used. This slight change helps reducing the number of queries made to the database.
- `_compute_fsm_task_count`: Correct the domain to actually look for `id` that are equals to the current tickets `ids`. This allows us to add an index on `helpdesk_ticket_id` to speed up the read_group, especially for the form view, where only 1 ticket is open / the computation is triggered. The index is `btree_not_null` to prevent wasting space, as the majority of `project.task` don't have related `helpdesk.ticket`.

## Results
On a database with 150k `helpdesk.ticket` on local machine. I've tested for 100 tasks also, as in the future we may decide to add the count to the list view for example.
- timing of `_compute_partner_ticket_count`:

| Ticket nb  |  Before  |   After   |
|:----------:|:--------:|:---------:|
|  1 ticket  | **0.2s** | **0.03s** |
| 100 ticket | **12s**  | **2.8s**  |

Gain of between **4x** (for computing 100 tickets) ~ **10x** (for computing a single ticket)

- timing of `compute_fsm_task_count`

| Ticket nb  |  Before   |   After   |
|:----------:|:---------:|:---------:|
|  1 ticket  | **50ms**  |  **6ms**  |
| 100 ticket | **280ms** | **235ms** |

Gain of between **1.2x (20%)** (for computing 100 tickets) ~ **8x** (for computing a single ticket)

Note that these numbers are undervalued, as it was tested on a local machine where the database is on the same machine as the web-server. Doesn't take into account network cost or database contention.

## Reference
task-3440810

when user clicks on call widget in mailing list contacts traceback will appear.

steps to produce:
1) install mass_mailing_sms and voip.
2) open one record and add mobile number.
3) click on mobile number.

traceback on sentry:
```
IndexError: list index out of range
  File "odoo/http.py", line 2123, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1699, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "odoo/service/model.py", line 133, in retrying
    result = func()
  File "odoo/http.py", line 1726, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1927, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 190, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 716, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 30, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 26, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 457, in call_kw
    result = _call_kw_model(method, model, args, kwargs)
  File "odoo/api.py", line 430, in _call_kw_model
    result = method(recs, *args, **kwargs)
  File "home/odoo/src/enterprise/saas-16.3/voip/models/voip_phonecall.py", line 299, in create_from_phone_widget
    partner_field_name = [k for k, v in fields if v.type == 'many2one' and v.comodel_name == 'res.partner'][0]
```

https://github.com/odoo/enterprise/blob/22992c1226268111ebf66f39214d8e15d0ede2e3/voip/models/voip_phonecall.py#L322 In the mailing.contact model, there is no field of type many2one with a comodel name of res.partner. As a result, the partner_field_name returns an empty list, and attempting to access the 0th element of an empty list is not possible.

sentry-4306579710

Forward-Port-Of: odoo/enterprise#44321