Merge pull request #5187 from matrix-org/dbkr/only_check_threepid_not_in_use_if_actually_registering

Only check 3pids not in use when registering

Allow client event serialization to be async

Expose DataStore._get_events as get_events_as_list

Use correct config option for ratelimiting in tests

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

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

We checked that 3pids were not already in use before we checked if
we were going to return the account previously registered in the
same UI auth session, in which case the 3pids will definitely
be in use.

https://github.com/vector-im/riot-web/issues/9586

This is in preparation for reaction work which requires it.

Migrate all tests to use the dict-based config format instead of hanging items off HomeserverConfig (#5171)

Fix CI after new release of isort

Prevents a SynapseError being raised inside of a IResolutionReceiver and instead opts to just return 0 results. This thus means that we have to lump a failed lookup and a blacklisted lookup together with the same error message, but the substitute should be generic enough to cover both cases.

Accidentally went straight to develop

This allows the client to complete the email last which is more
natual for the user. Without this stage, if the client would
complete the recaptcha (and terms, if enabled) stages and then the
registration request would complete because you've now completed a
flow, even if you were intending to complete the flow that's the
same except has email auth at the end.

Adding a dummy auth stage to the recaptcha-only flow means it's
always unambiguous which flow the client was trying to complete.
Longer term we should think about changing the protocol so the
client explicitly says which flow it's trying to complete.

https://github.com/vector-im/riot-web/issues/9586

Signed-off-by: Gergely Polonkai <gergely@polonkai.eu>