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...

MSC2260: change the default power level for m.room.aliases events

Fixes a bug where the alias would be added, but `PUT /directory/room/<alias>`
would return a 403.

I'm going to need another copy (hah!) of this.

We were sending device updates down both the federation stream and
device streams. This mean there was a race if the federation sender
worker processed the federation stream first, as when the sender checked
if there were new device updates the slaved ID generator hadn't been
updated with the new stream IDs and so returned nothing.

This situation is correctly handled by events/receipts/etc by not
sending updates down the federation stream and instead having the
federation sender worker listen on the other streams and poke the
transaction queues as appropriate.

Otherwise its just stale data, which may get deleted later anyway so
can't be relied on. It's also a bit of a shotgun if we're trying to get
the current state of a room we're not in.

We ended up only returning a single device, rather than all of them.