Support filtering by relations per MSC3440

[clokep]

Implements filtering via relations perMSC3440, specifically filtering for parent events which have:

• relation_types: Another event referring to them of particular relation type(s).
• relation_senders: Another event referring to them from particular sender(s).

This PR uses the unstable prefixes and required a bit of refactoring (I can split this work out to a separate PR if preferred):

• Updates the filter_* methods to be async
• Allow the FIlter to access the datastore (via HomeServer)

After that we can update the Filter implementation to take the additional filterings parameters and apply those in:

• The pagination infrastructure from the database.
• The manual checks against the event objects.

This should be reviewable commit-by-commit.

Fixes #11086

[clokep]

Separating this out to do a single query for all events might be a bit premature optimization, but doing a separate query per event seemed quite expensive.

[clokep]

This needed to be moved somewhere that it can have access to a HomeServer.

[squahtx]

I wonder if it'd be cleaner to pass the HomeServer as an argument to Filter.check instead of threading it through the constructor...
(I haven't checked)

[squahtx]

Can we treat empty lists as a filter allowing nothing through instead of no filter?

I'm imagining a case where someone writes the obvious code to query for something like "all events with a reaction from new users who joined within the last hour", where the list of users comes from another query.
It'd be unexpected for the filter to allow all events through if the query for newly-joined users happened to return 0 users.

[squahtx]

LGTM apart from the comments above

[clokep]

I wonder if it'd be cleaner to pass the HomeServer as an argument to Filter.check instead of threading it through the constructor... (I haven't checked)

I'm not sure that would be any clearer, it feels nicer to have it when we instantiate it (it should be fewer call sites), but I can try it if you would like!

Can we treat empty lists as a filter allowing nothing through instead of no filter?

I'm imagining a case where someone writes the obvious code to query for something like "all events with a reaction from new users who joined within the last hour", where the list of users comes from another query. It'd be unexpected for the filter to allow all events through if the query for newly-joined users happened to return 0 users.

Hmmm, the current filtering has things like:

A list of event types to include. If this list is absent then all event types are included.

Which is similar language to what I put into MSC3440. Is there a particular spot you're looking at to apply this? I think I implemented the filtering in the same way as the previous filters? Are you just asking for some more explicit is None checks?

[clokep]

@squahtx and I discussed this a bit on chat; he was hoping to see is (not) None checks added, but our conclusion was that it probably makes more sense to be consistent with the pre-existing code.

The conclusion is that we're going to leave this for now. We can re-visit in the future if necessary.