Remove RST comment, add bullets into list

data/event-schemas/schema/m.key.verification.cancel.yaml

@@ -27,28 +27,28 @@ properties:
           codes should use the Java package naming convention if not in the following
           list:
 
-          `m.user`: The user cancelled the verification.
+          * `m.user`: The user cancelled the verification.
 
-          `m.timeout`: The verification process timed out. Verification processes
+          * `m.timeout`: The verification process timed out. Verification processes
           can define their own timeout parameters.
 
-          `m.unknown_transaction`: The device does not know about the given transaction
+          * `m.unknown_transaction`: The device does not know about the given transaction
           ID.
 
-          `m.unknown_method`: The device does not know how to handle the requested
+          * `m.unknown_method`: The device does not know how to handle the requested
           method. This should be sent for `m.key.verification.start` messages and
           messages defined by individual verification processes.
 
-          `m.unexpected_message`: The device received an unexpected message. Typically
+          * `m.unexpected_message`: The device received an unexpected message. Typically
           raised when one of the parties is handling the verification out of order.
 
-          `m.key_mismatch`: The key was not verified.
+          * `m.key_mismatch`: The key was not verified.
 
-          `m.user_mismatch`: The expected user did not match the user verified.
+          * `m.user_mismatch`: The expected user did not match the user verified.
 
-          `m.invalid_message`: The message received was invalid.
+          * `m.invalid_message`: The message received was invalid.
 
-          `m.accepted`: A `m.key.verification.request` was accepted by a different
+          * `m.accepted`: A `m.key.verification.request` was accepted by a different
             device. The device receiving this error can ignore the verification request.
 
           Clients should be careful to avoid error loops. For example, if a device sends
@@ -56,8 +56,6 @@ properties:
           gets an unexpected response with `m.unexpected_message`, the client should not
           respond again with `m.unexpected_message` to avoid the other device potentially
           sending another error response.
-
-          .. The above blank line is important for RST.
     required:
       - transaction_id
       - code