PURPOSE

Mail: add tests for MailTemplate send_mail

Several flows use MailTemplate.send_mail() in batch, notably event email
scheduler which sends emails to event attendee in batch. This commit adds
tests around 'send_mail' method of MailTemplate model

  * add tests for batch: it is currently not supported hence using a loop but
    batch is going to be added soon, allowing to test the batch version works
    as intended;
  * add query counters, notably for batch mode and when dynamic reports are
    involved in templates;

Event: improve mail scheduler tests

Make them easier to improve and modify

  * use a dedicated setup (allowing to add specific unit tests on test data);
  * move initial asserts into its own unit test (to keep other tests shorter);
  * use available mocks for freezetime and sql.now;

Then add tests for registration emails, to check what happens for communication
scheduled right at registration time.

LINKS

Part of Task-3764894: Event: Allow using cron triggers for communication
Part of Task-3764891: Mail: Batch-ize MailTemplate send_mail
Part of Task-3164278: Mail: Batch send: ensure limit, avoid force
Part of Task-3084943: Event: Improve communication scheduler scalability

Forward-Port-Of: odoo/odoo#155717

When a crawler (eg Googlebot) come to visit your website, it grants you a limited amount of time and ressources, it's called "Crawler budget". If you have millions of URLs, it won't go through each one of them in a single go.

The best you can help those crawler, the better. The sitemap `lastmod` attribute, despite not being fully respected and trusted by crawlers, is one of the way you can still try to help them.

For website.pages, it's already done. But for controllers, it's not an easy thing to do as we have no way to automatically figure what are the relevant records/fields to look at to know the last update date. For instance, on the event pages, some pages content are mostly stored inside an `ir.ui.view`, but the title, hours etc are part of the event itself.
We can't just say "we take the last write_date of the record", it's wrong in 2 ways:
- The first one I just explained where we wouldn't be able to easily get all the elements part of the page rendering and would miss a possible element write_date, leaving an outdated date in `lastmod`.
- Then, there is another issue (which is more problematic in stable): the `write_date` is often updated for non website related purposes. For instance, on /partners/<partner>, we wouldn't be able to use the write date on odoo.com as the partners shown there (having a grade) are update every weeks in average, because of many fields, for instance: commission_plan_id, partner_weight, grade_id, ...

Still, there is a quick win possible in stable about forum posts which are not impacted by the 2 issues explained above:
- There is a dedicated `last_activity_date` field which is updated only when relevant information are modified. We can ensure to show a date which is not updated too frequently for no reason.
- All the forum.post information displayed on the page are stored inside the forum.post itself.

This commit is thus adding the `lastmod` on forum.post URLs in the sitemap in hope of not making Google waste time on (very) old posts.

Note: the `lastmod` has to be trustworthy and correct, if you set wrong
      or outdated info inside it, Google won't trust you/it anymore.