[REF] mail: optimize notification recipients data fetch through SQL query

In this commit we update _notify method of mail.message to fetch most data
related to notification process in a single query.  Indeed posting a
message can be a costly process, especially when involving several partners,
channels, depending on their notification status, user groups, ... Most
of the required data can be fetched in a single hand-tuned query.

Purpose is to lessen query count. Side effect of this commit is that code
is less recordset based and therefore more low-level. It is also harder to
customize the behavior through inheritance as it implies rewriting a bit
more of code.

This query is located in a private method on follower model. It takes
parameters allowing to either fetch data related to followers of a given
subtype, either related to some partners and channels. First use case is
related to the process of posting a message with a subtype that triggers
notification of followers. Second use case is related to notifying some
specific partners or channels of a given message. It takes notably into
consideration internal subtypes and active field of partners, allowing to
correctly handle corner case for deactivated followers and portal / share
partners.

Notification process is divided into two steps. First one is to compute
recipient data. Second one is to apply the result of this computation and
call the various notification mechanisms accordingly. Doing so allows to
easily re-call notification process or compute some data differently
if necessary.

API of notification methods is updated to allow passing notably the values
used to create the newly-posted message. It allows in some simple case to
avoid browsing message and partners when no notification is necessary. It
saves some queries in simple case like posting messages with specific
subtypes not often followed or logging notes without mentioning people.

This commit allows to save a few queries on several performance tests as
indicated by updated performance counters. Future commits will gradually
propagate the use of this data to further lessen query count.

This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.

0 files changed, 0 insertions, 0 deletions