* commit 'c530f9af4':
Un-remove room purge test
Incorporate review
Format changelog
Update changelog since this isn't going to be featured in 1.6.0
Also filter state events
Only filter if a filter was provided
Update copyright
Lint
Update copyrights
Changelog
Add tests for /search
Merge labels tests for /context and /messages
Add test case
Filter events_before and events_after in /context requests
* commit 'f496d2587':
Incorporate review
Factor out an _AsyncEventContextImpl (#6298)
Update synapse/storage/data_stores/main/schema/delta/56/event_labels.sql
Add more data to the event_labels table and fix the indexes
Add unstable feature flag
Lint
Incorporate review
Lint
Changelog
Add integration tests for /messages
Add more integration testing
Add integration tests for sync
Add unit tests
Add index on label
Implement filtering
Store labels for new events
Add database table for keeping track of labels on events
Currently we rely on `current_state_events` to figure out what rooms a
user was in and their last membership event in there. However, if the
server leaves the room then the table may be cleaned up and that
information is lost. So lets add a table that separately holds that
information.
This fixed the weirdness of 400 vs 404 as http status code in the case
the filter id is not known by the server.
As e.g. matrix-js-sdk expects 404 to catch this situation this leads
to unwanted behaviour.
Pull the checkers out to their own classes, rather than having them lost in a
massive 1000-line class which does everything.
This is also preparation for some more intelligent advertising of flows, as per #6100
because, frankly, it looked like it was written by an axe-murderer.
This should be a non-functional change, except that where `m.login.dummy` was
previously advertised *before* `m.login.terms`, it will now be advertised
afterwards. AFAICT that should have no effect, and will be more consistent with
the flows that involve passing a 3pid.
Python will return a tuple whether there are parentheses around the returned values or not.
I'm just sick of my editor complaining about this all over the place :)
When asking for the relations of an event, include the original event in the response. This will mostly be used for efficiently showing edit history, but could be useful in other circumstances.
