Notifications that aren't pre-filtered in time aren't sent by schedulers

Steps to reproduce:

1. Enable hourly notification email sending
2. Have slow notification pre-filtering with a queue of over an hour
3. Trigger a notification, e.g., with a mention

Expected result:

The notification email is sent later.

Actual result:

The notification email isn't sent at all.

Basically, what should happen is something like the following:

1. Notification X is triggered at 11:45
2. The hourly notification scheduler is triggered at 12:00 (and maybe sends some emails)
3. Pre-filtering of X happens at 12:15
4. The hourly notification scheduler at 13:00 doesn't include X because it is older than the last trigger time.

It seems that this code wasn't really adjusted to take pre-filtering into account. From what I saw in the code, live notifications don't seem to suffer from this problem.

On the first glance, it seems very simple to fix: just remove the date range filtering from the event queries. The user is removed from the mailListeners field in the Solr event store after the email has been sent. This is what live notifications seem to use to catch up after an instance restart. However, there is a problem: We only remove users from this field when the email has actually been sent. When we decide not to send an email, e.g., because the page is hidden, or the event has been marked as read, the user isn't removed from the mailListeners field. Therefore, removing the date range creates two problems:

1. It creates a performance/stability problem as it will make notification sending slower and more memory-hungry over time.
2. If old notifications suddenly aren't filtered out anymore, e.g., because the user enabled viewing hidden pages, suddenly lots of old notifications might be sent.

Possible alternative solutions could be to:

1. Store the pre-filtering time and filter based on that (when it exists)
2. Decide to update mailListeners also when based on post-filtering a notification isn't sent and then rely on mailListeners.

To me, the second option seems to be nicer as date-based filtering seems fragile but it's a non-trivial migration, in particular as during the first run, we might get lots of old events and we need to a) ensure that we use proper pagination to avoid performance issues and b) decide what to do with them, if we should send emails for old, missed notification events or not. If we don't send them, we need to carefully decide based on which criteria we discard them.