Remove aliases from /publicRooms response

Through attempting to land [Synapse#11667](matrix-org/synapse#11667) it was found that Synapse doesn't return the `aliases` property on `/publicRooms` as it was [removed](matrix-org/synapse#6970) by a [tracking issue](matrix-org/synapse#6898) referencing [MSC2432](#2432) as its base. Though MSC2432 does not make mention of this, the [document](https://docs.google.com/document/d/1NNDkobiFLeUkJtyj0H6qvKIedgvIkZnFKo78-03cGEk/edit) the MSC is based upon makes deliberate effort to mention the endpoint and the removal of `aliases`. Thus, it is determined as a likely accidental omission from the formal MSC and therefore the formal spec.

This has been corrected here by amending the MSC (per the process) and removing the field, basing itself off of the [spec PR for spaces](#3610) for diff clarity.

changelogs/client_server/newsfragments/3624.breaking

@@ -0,0 +1 @@
+The `aliases` property from the chunks returned by `/publicRooms`, as per [MSC2432](https://github.com/matrix-org/matrix-doc/pull/2432).

data/api/client-server/definitions/public_rooms_chunk.yaml

@@ -15,12 +15,6 @@
 type: object
 title: "PublicRoomsChunk"
 properties:
-  aliases:
-    type: array
-    description: Aliases of the room. May be empty.
-    items:
-      type: string
-    example: ["#general:example.org"]
   canonical_alias:
     type: string
     description: The canonical alias of the room, if any.

data/api/client-server/definitions/public_rooms_response.yaml

@@ -55,7 +55,6 @@ properties:
 example: {
   "chunk": [
     {
-      "aliases": ["#murrays:cheese.bar"],
       "avatar_url": "mxc://bleecker.street/CHEDDARandBRIE",
       "guest_can_join": false,
       "name": "CHEESE",

data/api/client-server/space_hierarchy.yaml

@@ -100,7 +100,6 @@ paths:
                   "join_rule": "public",
                   "room_type": "m.space",
                   "num_joined_members": 42,
-                  "aliases": ["#general:example.org"],
                   "canonical_alias": "#general:example.org",
                   "children_state": [
                     {

data/api/server-server/public_rooms.yaml

@@ -178,7 +178,6 @@ paths:
             application/json: {
               "chunk": [
                 {
-                  "aliases": ["#murrays:cheese.bar"],
                   "avatar_url": "mxc://bleecker.street/CHEDDARandBRIE",
                   "guest_can_join": false,
                   "name": "CHEESE",

data/api/server-server/space_hierarchy.yaml

@@ -74,7 +74,6 @@ paths:
                 "join_rule": "public",
                 "room_type": "m.space",
                 "num_joined_members": 42,
-                "aliases": ["#general:example.org"],
                 "canonical_alias": "#general:example.org",
                 "allowed_room_ids": [],
                 "children_state": [
@@ -103,7 +102,6 @@ paths:
                   "join_rule": "restricted",
                   "room_type": "m.space",
                   "num_joined_members": 42,
-                  "aliases": ["#general:example.org"],
                   "canonical_alias": "#general:example.org",
                   "allowed_room_ids": [
                     "!upstream:example.org"

proposals/2403-knock.md

@@ -196,9 +196,6 @@ contain this information:
 
 ```json
 {
-  "aliases": [
-    "#murrays:cheese.bar"
-  ],
   "avatar_url": "mxc://bleecker.street/CHEDDARandBRIE",
   "guest_can_join": false,
   "name": "CHEESE",
@@ -436,7 +433,7 @@ The room is unknown to the remote server. Example reply:
 
 ## Restrictions
 There are restrictions to being able to set this membership, as well as
-accepting or denying the knock.  A formal description of the changes to the auth rules is given below; 
+accepting or denying the knock.  A formal description of the changes to the auth rules is given below;
 first we summarise the semantics of the proposed changes.
 
 ### Current membership
@@ -604,7 +601,7 @@ partake in. That is why this proposal enables the `knock` join rule, in
 order to allow room admins to opt in to this behaviour.
 
 # Alternatives
-The possibility of initiating a knock by sending EDUs between users instead of sending 
+The possibility of initiating a knock by sending EDUs between users instead of sending
 a membership state event into a room has been raised. This is an ongoing discussion
 occurring at https://github.com/matrix-org/matrix-doc/pull/2403/files#r573180627.
 

proposals/2432-revised-alias-publishing.md

@@ -148,6 +148,11 @@ rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) and
    Servers might also choose to allow access to other users such as server
    administrators.
 
+ * [`GET /_matrix/client/r0/publicRooms`](https://matrix.org/docs/spec/client_server/r0.6.0#get-matrix-client-r0-publicrooms)
+   (and the `POST` variant) no longer return `aliases` as part of `PublicRoomsChunk`.
+   Clients do not appear to make use of this field, and `canonical_alias` is maintained
+   to provide similar information.
+
 Various APIs are currently subject to implementation-defined access
 restrictions. No change to the specification is introduced in this regard
 (implementations will continue to be free to impose their own

proposals/2946-spaces-summary.md

@@ -125,7 +125,6 @@ GET /_matrix/client/v1/rooms/%21ol19s%3Ableecker.street/hierarchy?
             "world_readable": true,
             "join_rule": "public",
             "canonical_alias": "#cheese:bleecker.street",
-            "aliases": ["#cheese:bleecker.street"],
 
             // Added fields
             "room_type": "m.space",