Remove RST alert directives, replace with simple Markdown formatting

data/api/client-server/administrative_contact.yaml

@@ -96,7 +96,7 @@ paths:
         This endpoint is deprecated in favour of the more specific ``/3pid/add``
         and ``/3pid/bind`` endpoints.
 
-        .. Note::
+        **Note:**
         Previously this endpoint supported a ``bind`` parameter. This parameter
         has been removed, making this endpoint behave as though it was ``false``.
         This results in this endpoint being an equivalent to ``/3pid/bind`` rather

data/api/client-server/content-repo.yaml

@@ -347,7 +347,7 @@ paths:
         Get information about a URL for the client. Typically this is called when a
         client sees a URL in a message and wants to render a preview for the user.
 
-        .. Note::
+        **Note:**
         Clients should consider avoiding this endpoint for URLs posted in encrypted
         rooms. Encrypted rooms often contain more sensitive information the users
         do not want to share with the homeserver, and this can mean that the URLs

data/api/client-server/directory.yaml

@@ -132,7 +132,7 @@ paths:
         Servers may choose to implement additional access control checks here, for instance that
         room aliases can only be deleted by their creator or a server administrator.
 
-        .. Note::
+        **Note:**
         Servers may choose to update the ``alt_aliases`` for the ``m.room.canonical_alias``
         state event in the room when an alias is removed. Servers which choose to update the
         canonical alias event are recommended to, in addition to their other relevant permission
@@ -184,7 +184,7 @@ paths:
         such as allowing server administrators to view aliases regardless of
         membership.
 
-        .. Note::
+        **Note:**
         Clients are recommended not to display this list of aliases prominently
         as they are not curated, unlike those listed in the ``m.room.canonical_alias``
         state event.

data/api/server-server/backfill.yaml

@@ -64,7 +64,7 @@ paths:
             A transaction containing the PDUs that preceded the given event(s), including the given
             event(s), up to the given limit.
 
-            .. Note::
+            **Note:**
             Though the PDU definitions require that ``prev_events`` and ``auth_events`` be limited
             in number, the response of backfill MUST NOT be validated on these specific restrictions.
 

data/api/server-server/invites-v2.yaml

@@ -31,7 +31,7 @@ paths:
     put:
       summary: Invites a remote user to a room
       description: |-
-        .. Note::
+        **Note:**
         This API is nearly identical to the v1 API with the exception of the request
         body being different, and the response format fixed.
 

data/api/server-server/joins-v1.yaml

@@ -176,9 +176,8 @@ paths:
     put:
       summary: Submit a signed join event to a resident server
       description: |-
-        .. Note::
+        **Note:**
-           Servers should instead prefer to use the v2 ``/send_join``
+        Servers should instead prefer to use the v2 ``/send_join`` endpoint.
-           endpoint.
 
         Submits a signed join event to the resident server for it
         to accept it into the room's graph. Note that events have

data/api/server-server/joins-v2.yaml

@@ -33,7 +33,7 @@ paths:
     put:
       summary: Submit a signed join event to a resident server
       description: |-
-        .. Note::
+        **Note:**
         This API is nearly identical to the v1 API with the
         exception of the response format being fixed.
 

data/api/server-server/leaving-v1.yaml

@@ -143,9 +143,8 @@ paths:
     put:
       summary: Submit a signed leave event to a resident server
       description: |-
-        .. Note::
+        **Note:**
-           Servers should instead prefer to use the v2 ``/send_leave``
+        Servers should instead prefer to use the v2 ``/send_leave`` endpoint.
-           endpoint.
 
         Submits a signed leave event to the resident server for it
         to accept it into the room's graph. Note that events have

data/api/server-server/leaving-v2.yaml

@@ -33,7 +33,7 @@ paths:
     put:
       summary: Submit a signed leave event to a resident server
       description: |-
-        .. Note::
+        **Note:**
         This API is nearly identical to the v1 API with the
         exception of the response format being fixed.
 

data/event-schemas/schema/m.room.power_levels.yaml

@@ -31,7 +31,7 @@ description: |-
   ``m.room.power_levels`` event, or if the room contains no ``m.room.power_levels``
   event.
 
-  .. NOTE::
+  **Note:**
 
   As noted above, in the absence of an ``m.room.power_levels`` event, the
   ``state_default`` is 0, and all users are considered to have power level 0.

data/event-schemas/schema/m.room.server_acl.yaml

@@ -22,18 +22,18 @@ description: |-
   #. If the server name matches an entry in the ``allow`` list, allow.
   #. Otherwise, deny.
 
-  .. Note::
+  **Note:**
   Server ACLs do not restrict the events relative to the room DAG via authorisation
   rules, but instead act purely at the network layer to determine which servers are
   allowed to connect and interact with a given room.
 
-  .. WARNING::
+  **Warning:**
   Failing to provide an ``allow`` rule of some kind will prevent **all**
   servers from participating in the room, including the sender. This renders
   the room unusable. A common allow rule is ``[ "*" ]`` which would still
   permit the use of the ``deny`` list without losing the room.
 
-  .. WARNING::
+  **Warning:**
   All compliant servers must implement server ACLs.  However, legacy or noncompliant
   servers exist which do not uphold ACLs, and these MUST be manually appended to
   the denied hosts list when setting an ACL to prevent them from leaking events from