Fix RST building

Specs repos now build with tox -e docs and this fails since warnings are
treated as errors. Fix issues, see below for details.

tox -e docs fails with:

1)
queens/remove-pool-group-from-zaqar.rst:402: WARNING: Inline emphasis start-string without end-string.

Fix RST syntax.

2) queens/support-md5-of-body.rst:: WARNING: document isn't included in any toctree

Include document in toctree.

3) rocky/queue-filter-support.rst:38: WARNING: Literal block expected; none found.

Fixed RST.

4) rocky/remove-format-constraint-of-client-id.rst:13: WARNING: Title overline too short.

Fixed RST.

5) rocky/remove-format-constraint-of-client-id.rst:37: ERROR: Unexpected indentation.
Fixed RST.

6) rocky/subscription-filtering-tags.rst:82: WARNING: Bullet list ends without a blank line; unexpected unindent.
Fixed RST.

Change-Id: Ide32b348d68e35f8f531c30ddae680d085553b68

specs/queens/index.rst

@@ -10,3 +10,4 @@
    support-more-backoff-functions
    delayed-queues
    remove-pool-group-from-zaqar
+   support-md5-of-body

specs/queens/remove-pool-group-from-zaqar.rst

@@ -399,12 +399,12 @@ flavor in the pool API. This can be compatible with the old way.
 
 #. Old Way:
 
-   *. configure group in pool API and in flavor API;
+   * configure group in pool API and in flavor API;
 
 #. New Way:
 
-   *. configure pool_list in flavor API
-   *. add a pool to flavor:
+   * configure pool_list in flavor API
+   * add a pool to flavor:
 
       #. method one: update pool_list in flavor API
       #. method two: config a pool with the flavor in pool API.

specs/rocky/queue-filter-support.rst

@@ -35,7 +35,7 @@ Proposed change
 When queue listing, we add filter option in query string parameters
 like this ::
 
-GET /v2/queues?key1=value1&key2=value2&name=value3
+  GET /v2/queues?key1=value1&key2=value2&name=value3
 
 If metadata of queue and name is consistent with the filter, the queues will be
 listed to the user, otherwise the queue will be filtered.
@@ -44,8 +44,9 @@ to user.
 
 API Impact
 -----------
-Lists queues
-GET: /v2/queues?key1=value1&key2=value2
+Lists queues::
+
+  GET: /v2/queues?key1=value1&key2=value2
 
   RESPONSE CODE: 200
 

specs/rocky/remove-format-constraint-of-client-id.rst

@@ -10,9 +10,9 @@
   For help with syntax, see http://sphinx-doc.org/rest.html
   To test out your formatting, see http://www.tele3.cz/jbar/rest/rest.html
 
-====================================
+=====================================
 Remove format constraint of client id
-====================================
+=====================================
 
 https://blueprints.launchpad.net/zaqar/+spec/remove-format-constraint-of-client-id
 
@@ -31,15 +31,15 @@ user id in LDAP as client id, but Zaqar doesn't allow this now.
 
 Proposed change
 ===============
-* Add Three config options::
+* Add Three config options:
 
-  # 'client_id_uuid_safe': Defines the format of client id, the value could be
-    "strict" or "off". "strict" means the format of client id must be uuid,
-    "off" means the restriction be removed. The default value is 'strict'.
-  # 'min_length_client_id': Defines the minimum length of client id if remove
-    the uuid restriction. Default value is 10.
-  # 'max_length_client_id': Defines the maximum length of client id if
-    remove the uuid restriction. Default value is 36.
+  #. 'client_id_uuid_safe': Defines the format of client id, the value could be
+     "strict" or "off". "strict" means the format of client id must be uuid,
+     "off" means the restriction be removed. The default value is 'strict'.
+  #. 'min_length_client_id': Defines the minimum length of client id if remove
+     the uuid restriction. Default value is 10.
+  #. 'max_length_client_id': Defines the maximum length of client id if
+     remove the uuid restriction. Default value is 36.
 
 * Will change the method 'require_client_id' in wsgi/helpers.py to support
   validating the different format of client id.

specs/rocky/subscription-filtering-tags.rst

@@ -79,20 +79,21 @@ Finally, zaqar decides which subscribers the message should be sent to
 according to the following rules:
 
 * If the subscriber does not have any filter_policies, all messages will be
-sent to the subscriber.
+  sent to the subscriber.
 
-* If the message does not contain any filter_policies, it will not be sent to
-the subscriber which has filter_policies.
+* If the message does not contain any filter_policies, it will not be
+  sent to the subscriber which has filter_policies.
 
 * If the message and the subscriber's filter_policies have intersecting
-collections, the message will be sent to the subscriber.
+  collections, the message will be sent to the subscriber.
 
-* If the message and the subscriber both have filter_policies, but there is no
-intersection set, no message will be sent to the subscriber.
+* If the message and the subscriber both have filter_policies, but
+  there is no intersection set, no message will be sent to the
+  subscriber.
 
-* The relationship of the content in `order_placed` is *or*, it means that the
-message will be sent to the subscriptions that match anyone filters in
-`order_placed`.
+* The relationship of the content in `order_placed` is *or*, it means
+  that the message will be sent to the subscriptions that match anyone
+  filters in `order_placed`.
 
 Drawbacks
 ---------
@@ -136,4 +137,4 @@ None
 References
 ==========
 
-[1] https://docs.aws.amazon.com/sns/latest/dg/message-filtering.html
+[1] https://docs.aws.amazon.com/sns/latest/dg/message-filtering.html