... and use it in places where it's trivial to do so.

This will make it easier to pass room versions into the FrozenEvent
constructors.

It's called from all over the shop, so this one's a bit messy.

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

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

as per MSC2260

* Bump signedjson to 1.1

... so that we can use the type definitions

* Fix breakage caused by upgrade to signedjson 1.1

Thanks, @illicitonion...

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

These are easier to work with than the strings and we normally have one around.

This fixes `FederationHander._persist_auth_tree` which was passing a
RoomVersion object into event_auth.check instead of a string.

This is so that we don't have to rely on pulling it out from `current_state_events` table.

There are quite a few places that we assume that a redaction event has a
corresponding `redacts` key, which is not always the case. So lets
cheekily make it so that event.redacts just returns None instead.

... since the whole response is huge.

We even need to break up the assertions, since kibana otherwise truncates them.

* Port synapse.replication.tcp to async/await

* Newsfile

* Correctly document type of on_<FOO> functions as async

* Don't be overenthusiastic with the asyncing....

Allow REST endpoint implemnentations to raise a RedirectException, which will
redirect the user's browser to a given location.

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 is pretty pointless. Let's just use SynapseError.

Signed-off-by: Manuel Stahl <manuel.stahl@awesome-technologies.de>

Fixes #6552 

This was ill-advised. We can't modify verify_keys here, because the response
object has already been signed by the requested key.

Furthermore, it's somewhat unnecessary because existing versions of Synapse
(which get upset that the notary key isn't present in verify_keys) will fall
back to a direct fetch via `/key/v2/server`.

Also: more tests for fetching keys via perspectives: it would be nice if we actually tested when our fetcher can't talk to our notary impl.

... to make way for a new method which just returns the event ids

Lift the restriction that *all* the keys used for signing v2 key responses be
present in verify_keys.

Fixes #6596.

* Kill off redundant SynapseRequestFactory

We already get the Site via the Channel, so there's no need for a dedicated
RequestFactory: we can just use the right constructor.

* Workaround for error when fetching notary's own key

As a notary server, when we return our own keys, include all of our signing
keys in verify_keys.

This is a workaround for #6596.

We already get the Site via the Channel, so there's no need for a dedicated
RequestFactory: we can just use the right constructor.