## 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