Make label-based filtering support edits

[babolivier]

Support the latest changes on MSC2326 wrt edits.

The summary is that, when an edit of an event with labels comes through (whether it changes the list of labels or not), we need to:

• return the edit when filtering on one of the labels from the edit's list of labels (and not the original event, nor both)
• don't return any event that's either the original event or one of its edits when filtering on a label that's been removed by an edit

To do this, every time we process an edit, we:

• delete every label that was associated with the edit's original event (or another edit of that original event)
• if the edit features a list of labels, store those with the event ID of the edit

Blocked on #6329 because I plan on iterating on its changes to add tests for this one.

[richvdh]

before I dig any more deeply into this:

what is the permissions model here? it looks like I could generate an edit event which changes the labels on an event sent by someone else? (Edit: I'm going to take this to the MSC)

Edit edit: I've spent the last hour chasing MSCs and concluded that MSC1849 doesn't really discuss the permission model, but synapse does do some basic permissions checks. It does so by only checking for edits when it serves them to the client, and checking that the senders match. We'll need to do the equivalent here.

stale

[richvdh]

I still think this approach is somewhat flawed.

[richvdh]

what if the update arrives before the original event?

[babolivier]

This is the wrong approach for handling edits, in that we can't ensure that updates arrive in the right order, or that updates even arrive after the original event. A correct implementation would be calculating the list of labels when processing edits when the client requests events.