We forgot to filter out aliases from /sync state blocks as well as the timeline.

We're in the middle of properly mitigating spam caused by malicious aliases being added to a room. However, until this work fully lands, we temporarily filter out all m.room.aliases events from /sync and /messages on the CS API, to remove abusive aliases. This is considered acceptable as m.room.aliases events were never a reliable record of the given alias->id mapping and were purely informational, and in their current state do more harm than good.

Workaround for jaraco/zipp#40

If they don't then the device lists are probably out of sync.

add device signatures to device key query results

We were looking at the wrong event type (`m.room.encryption` vs
`m.room.encrypted`).

Also fixup the duplicate `EvenTypes` entries.

Introduced in #6776.

We were in fact only deleting stale marker when we got an incremental
update, rather than when we did a full resync.

Pass room_version into add_hashes_and_signatures

Make `get_room_version` return a RoomVersion object

So that we can start factoring out some of this boilerplatey boilerplate.

... to make way for a forthcoming get_room_version which returns a RoomVersion
object.

as per MSC2260

Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>

When a server leaves a room it may stop sharing a room with remote
users, and thus not get any updates to their device lists. So we need to
check for this case and delete those device lists from the cache.

We don't need to do this if we stop sharing a room because the remote
user leaves the room, because we track that case via looking at
membership changes.

If we detect that the remote users' keys may have changed then we should
attempt to resync against the remote server rather than using the
(potentially) stale local cache.

* Bump signedjson to 1.1

... so that we can use the type definitions

* Fix breakage caused by upgrade to signedjson 1.1

Thanks, @illicitonion...