Add support for room version 10

[H-Shay]

The PR adds support for room version 10, which is now a part of the spec. Specifically, it adds a check that will fail incoming events with non-int powerlevels, as well as adding support in room version 10 for the knock_restricted join rule. Fixes #13084.

[H-Shay]

I added the check here because the spec seems to indicate that the power level check failure should be "rejected under the authorization rules " and this was an auth check function relating to room versions, so it seemed the appropriate place. If it's not I am happy to move it.

[squahtx]

Can we move this to _check_power_levels, where we apply the rest of the auth rules under item 10. in the spec (https://spec.matrix.org/latest/rooms/v10/#authorization-rules) ?

[H-Shay]

Yes, done in 808dd94.

[erikjohnston]

Does this not also need users?

[squahtx]

I think we need to include users too. The spec wording is:

2. [New in this version] If either of the keys events or notifications in content are present and not a dictionary with values that are integers, reject.
3. If users key in content is not a dictionary with keys that are valid user IDs with values that are integers, reject.

and 2. doesn't mention users because it's covered in 3. We currently validate a weaker form of 3. in _check_power_levels, where we check if the value is parseable as an integer.

[H-Shay]

Thanks for pointing this out, I added users and removed the weaker check in _check_power_levels as it is superseded by this change.

[squahtx]

Looks good, some minor suggestions.

[squahtx]

Can we move this to _check_power_levels, where we apply the rest of the auth rules under item 10. in the spec (https://spec.matrix.org/latest/rooms/v10/#authorization-rules) ?

[squahtx]

I think we need to include users too. The spec wording is:

2. [New in this version] If either of the keys events or notifications in content are present and not a dictionary with values that are integers, reject.
3. If users key in content is not a dictionary with keys that are valid user IDs with values that are integers, reject.

and 2. doesn't mention users because it's covered in 3. We currently validate a weaker form of 3. in _check_power_levels, where we check if the value is parseable as an integer.

[squahtx]

Thanks for making the changes!

[squahtx]

Looks really good, just some incredibly minor nits/suggestions:

[squahtx]

It might be confusing to get errors like "100 must be an integer." when power levels are strings. We could use repr (!r) to format the error, so that strings will be single quoted, which is a tiny bit clearer.

Suggested change

	if not isinstance(v, int):
	raise SynapseError(400, f"{v} must be an integer.")
	if k in {"events", "notifications", "users"}:
	if not isinstance(v, dict) or not all(
	isinstance(v, int) for v in v.values()
	):
	raise SynapseError(
	400, f"{v} must be a dict wherein all the values are integers."
	)
	if not isinstance(v, int):
	raise SynapseError(400, f"{v!r} must be an integer.")
	if k in {"events", "notifications", "users"}:
	if not isinstance(v, dict) or not all(
	isinstance(v, int) for v in v.values()
	):
	raise SynapseError(
	400, f"{v!r} must be a dict wherein all the values are integers."
	)

[H-Shay]

I haven't seen !r before, thanks for sharing!

[DMRobertson]

The notation was introduced in Python 3's str.format() and has made its way into f-strings.

https://pyformat.info/#conversion_flags describes the relevant part of str.format. I think most people would prefer to use f-strings these days though.

[H-Shay]

I also was unaware of pyformat.info. That website looks very useful, thank you for mentioning it.

[squahtx]

lgtm!