Partially addresses #47424.

First N+1: we may have loaded a user's notification settings already, but not
have loaded their sources. Because we're iterating through, we'd potentially
load sources that are completely unrelated, just because they belong to this
user.

Second N+1: we do a separate query for each user who could be subscribed to or
unsubcribed from the target. It's actually more efficient in this case to get
all subscriptions at once, as we will need to check most of them.

We can fix both by the slightly unpleasant means of checking IDs manually,
rather than object equality.

Closes #23460

Adds `#build_notification_recipients` to `NotificationRecipientService`
that returns the `NotificationRecipient` objects in order to be able to
access the new attribute `reason`.

This new attribute is used in the different notifier methods in order to
add the reason as a header: `X-GitLab-NotificationReason`.

Only the reason with the most priority gets sent.

factor out #suitable_notification_level? and check manually by
notification level. this makes the notification logic clear and actually
reflect what is in the documentation as to what should happen with each
setting.

since we're just adding them as a member, the permission may still
return false.

it's not there in the case of personal snippets, f. ex., and we've
already guarded against its being missing in #find_notification_setting