Specify room version 10: knock_restricted and int power levels (#1099)

* Clarification on historical power level handling

* Revert "Clarification on historical power level handling"

This reverts commit f443b3d5a9afac3095b14a72ec471ba06f4cc78b.

* Clean up

* Let us try this again not using VS Code

* Markdown is full of mysteries

* Move stringy power levels to room versions

* Describe range

* Fix minor issues with previous room version stuff

* Copy/paste v9 into v10

* Describe deprecated formatting

* Paste unmodified auth rules from v8 into v10

* Move 9.1 to 9.3, add 9.1 and 9.2 for integer enforcement

* Add knock_restricted to v10 auth

* Misc cleanup and clarification for fragments

* Describe `knock_restricted` client changes

* Changelogs

* spelling

* Apply suggestions from code review

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

* Apply code review suggestions manually

* Fix v9 redactions

* Fix auth rules clarity issues

* Apply suggestions from code review

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

* Remove false integer requirements

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

content/rooms/fragments/v1-deprecated-formatting-off-spec.md

@@ -0,0 +1,13 @@
+---
+toc_hide: true
+---
+
+Events sent into rooms of this version can have formats which are different
+from their normal schema. Those cases are documented here.
+
+{{% boxes/warning %}}
+The behaviour described here is preserved strictly for backwards compatibility
+only. A homeserver should take reasonable precautions to prevent users from
+sending these so-called "malformed" events, and must never rely on the behaviours
+described here as a default.
+{{% /boxes/warning %}}

content/rooms/fragments/v1-stringy-power-levels.md

@@ -0,0 +1,43 @@
+---
+toc_hide: true
+---
+
+##### `m.room.power_levels` events accept values as strings
+
+In order to maintain backwards compatibility with early implementations,
+each of the integer-valued properties within
+[`m.room.power_levels`](/client-server-api#mroompower_levels) events can
+be encoded as strings instead of integers. This includes the nested values
+within the `events`, `notifications` and `users` properties.
+For example, the following is a valid `m.room.power_levels` event in this room version:
+
+```json
+{
+  "content": {
+    "ban": "50",
+    "events": {
+      "m.room.power_levels": "100"
+    },
+    "events_default": "0",
+    "state_default": "50",
+    "users": {
+      "@example:localhost": "100"
+    },
+    "users_default": "0"
+  },
+  "origin_server_ts": 1432735824653,
+  "room_id": "!jEsUZKDJdhlrceRyVU:example.org",
+  "sender": "@example:example.org",
+  "state_key": "",
+  "type": "m.room.power_levels"
+}
+```
+
+When the value is representative of an integer, they must be the following format:
+
+* a single base 10 integer, no float values or decimal points, optionally with
+  any number of leading zeroes (`"100"`, `"000100"`);
+* optionally prefixed with a single `-` or `+` character before the integer (`"+100"`,
+  `"-100"`).
+* optionally with any number of leading or trailing whitespace characters (`" 100 "`,
+  `" 00100 "`, `" +100 "`, `" -100 "`);

content/rooms/fragments/v9-redactions.md

@@ -0,0 +1,51 @@
+---
+toc_hide: true
+---
+
+{{% added-in this=true %}} `m.room.member` events now keep `join_authorised_via_users_server`
+in addition to other keys in `content` when being redacted.
+
+{{% boxes/rationale %}}
+Without the `join_authorised_via_users_server` property, redacted join events
+can become invalid when verifying the auth chain of a given event, thus creating
+a split-brain scenario where the user is able to speak from one server's
+perspective but most others will continually reject their events.
+
+This can theoretically be worked around with a rejoin to the room, being careful
+not to use the faulty events as `prev_events`, though instead it is encouraged
+to use v9 rooms over v8 rooms to outright avoid the situation.
+
+[Issue #3373](https://github.com/matrix-org/matrix-doc/issues/3373) has further
+information.
+{{% /boxes/rationale %}}
+
+The full redaction algorithm follows.
+
+Upon receipt of a redaction event, the server must strip off any keys
+not in the following list:
+
+-   `event_id`
+-   `type`
+-   `room_id`
+-   `sender`
+-   `state_key`
+-   `content`
+-   `hashes`
+-   `signatures`
+-   `depth`
+-   `prev_events`
+-   `prev_state`
+-   `auth_events`
+-   `origin`
+-   `origin_server_ts`
+-   `membership`
+
+The content object must also be stripped of all keys, unless it is one
+of one of the following event types:
+
+-   `m.room.member` allows keys `membership`, `join_authorised_via_users_server`.
+-   `m.room.create` allows key `creator`.
+-   `m.room.join_rules` allows keys `join_rule`, `allow`.
+-   `m.room.power_levels` allows keys `ban`, `events`, `events_default`,
+    `kick`, `redact`, `state_default`, `users`, `users_default`.
+-   `m.room.history_visibility` allows key `history_visibility`.