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
+   * configure pool_list in flavor API
-   *. add a pool to flavor:
+   * 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
+Lists queues::
-GET: /v2/queues?key1=value1&key2=value2
+
+  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,14 +31,14 @@ 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
+  #. '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
+  #. '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
+  #. '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

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
+* If the message does not contain any filter_policies, it will not be
-the subscriber which has filter_policies.
+  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
+* If the message and the subscriber both have filter_policies, but
-intersection set, no message will be sent to the subscriber.
+  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
+* The relationship of the content in `order_placed` is *or*, it means
-message will be sent to the subscriptions that match anyone filters in
+  that the message will be sent to the subscriptions that match anyone
-`order_placed`.
+  filters in `order_placed`.
 
 Drawbacks
 ---------