Up until now, the `sent` event type was never processed, probably because it "made no sense", as an unsent email would never trigger an event.
However, it makes sense to process it because you may have a local relay that transmits mails over to the mail provider. In those circumstances, you should have 2 "sent" events (one from the relay and another one from the provider).
Also marked some useless parts of code for removal.
@Tecnativa TT32365
When searching for failed messages, [this line][1] made Odoo search messages in 2 steps:
1. Find which `mail.tracking.email` records are in those states.
2. Find which of them belong to the present `mail.message` records.
Step 2 could take a long time if there were a lot of failures in a DB. In our proven case, this made loading the `res.partner` form view take about ~6s per partner. It was also slowing down other views.
With this simple fix, [that nasty line linked above][1] is solved with just one query like this:
```SQL
SELECT "mail_message".id FROM "mail_tracking_email" as "mail_message__mail_tracking_ids","mail_message"
WHERE ("mail_message"."id"="mail_message__mail_tracking_ids"."maiL_message_id") AND (((("mail_message"."model" = 'res.partner') AND ("mail_message"."mail_tracking_needs_action" = true)) AND ("mail_message__mail_tracking_ids"."state" in ('rejected','error','bounced','soft-bounced','spam'))) AND ("mail_message"."res_id" in (1000)))
ORDER BY "mail_message"."id" DESC
```
Thus this makes the forms load at normal speed again.
[1]: 8bd98212b8/mail_tracking/models/mail_thread.py (L25)
Before this commit, some methods with views crashes trying to
process 'failed_message_ids' field.
After this commit the 'failed_message_ids' field description
is properly generated.
Previous this commit, failed messages widget data wasn't updated properly when you
set as reviewed/retry the last message displayed.
This commit resolve the problem and improves the "set as reviewed" action to avoid
multi-user inconsistencies (don't toggle the value).
- Any model inheriting from mail.thread will have a filter available to
obtain records with errors in their messages trackings.
- The messages can be marked as done to avoid false positives when the
issues are solved.
On our server,
queries based on "mail_tracking_event"."tracking_email_id" improved from 501,924 ms to 1,840 ms
queries based on "mail_tracking_email"."mail_message_id" improved from 167,436 ms to 3,223 ms
The last ones are run several times when a thread has many messages