change readthedocs theme to material

doc/modules/mod_adhoc.md

@@ -1,23 +1,23 @@
-### Module Description
+## Module Description
 This module implements [XEP-0050: Ad-Hoc Commands](http://xmpp.org/extensions/xep-0050.html). It allows XMPP entities to remotely execute various commands using forms.
 
-### Options
+## Options
 
-#### `modules.mod_adhoc.iqdisc.type`
+### `modules.mod_adhoc.iqdisc.type`
 * **Syntax:** string, one of `"one_queue"`, `"no_queue"`, `"queues"`, `"parallel"`
 * **Default:** `"one_queue"`
 
 Strategy to handle incoming stanzas. For details, please refer to
 [IQ processing policies](../../advanced-configuration/Modules/#iq-processing-policies).
 
-#### `modules.mod_adhoc.report_commands_node`
+### `modules.mod_adhoc.report_commands_node`
 * **Syntax:** boolean
 * **Default:** `false`
 * **Example:** `report_commands_node = true`
 
 Determines whether the Ad-Hoc Commands should be announced upon Service Discovery.
 
-### Example configuration
+## Example configuration
 ```toml
 [modules.mod_adhoc]
   report_commands_node = true

doc/modules/mod_amp.md

@@ -1,4 +1,4 @@
-### Module Description
+## Module Description
 
 This module enables support for a subset of the functionality described under
 [XEP-0079: Advanced Message
@@ -8,8 +8,7 @@ provide features related to timed delivery, i.e the `expire-at` condition.
 The `error` and `notify` actions are supported, while `alert` and `drop` are
 not. See more below, under XEP Support.
 
-
-### Options
+## Options
 
 none
 
@@ -19,22 +18,22 @@ none
 [modules.mod_amp]
 ```
 
-### XEP Support
+## XEP Support
 
 What follows is a short description of which parts of the XEP-0079 specification
 mod_amp supports.
 
-* 2.1.1 Service Discovery
+2.1.1 Service Discovery
 
   * Both the service discovery information response (Ex.1, 2) and the
     request/response for individual actions and conditions (Ex.3, 4) are
     **supported**.
 
-* 2.1.2 Specifying Semantics
+2.1.2 Specifying Semantics
 
   * "Per-hop" rule semantics are **not supported**, i.e. ignored.
 
-* 2.2 Server Processing
+2.2 Server Processing
 
   * 2.2.1 Validating Semantics: Performed as in the XEP. The first message to
   fail validation determines the error message.
@@ -43,46 +42,46 @@ mod_amp supports.
   * 2.2.4 **supported** for actions: `error` and `notify`.
   * 2.2.5 **supported** for events: `error` and `notify`.
 
-* 3.3 Defined Conditions
+3.3 Defined Conditions
 
   * 3.3.1 deliver: **supported** for values: `direct`, `stored`, and `none`. The `stored` condition works with `mod_mam` and `mod_offline`. **Note**: if both `mod_mam` and `mod_offline` are enabled, some delivery conditions may not work correctly.
   * 3.3.2 expire-at: **not supported**
   * 3.3.3 match-resource: **supported**
 
-* 3.4 Defined Actions
+3.4 Defined Actions
 
   * 3.4.1 alert: **not supported**
   * 3.4.2 drop: **not supported**
   * 3.4.3 error: **supported**
   * 3.4.4 notify: **supported**. Notifications for the `stored` and `direct` conditions are sent as soon as the message has been stored or sent to the recipient.
 
-* 6. Error Handling
+6\. Error Handling
 
   * 6.2.1 Unsupported Action: **supported**
   * 6.2.2 Unsupported Condition: **supported**
   * 6.2.3 Not Acceptable: **supported**
   * 6.2.4 Service Unavailable is **not supported**, as it pertains to "per-hop" rule processing
   * 6.2.5 Undefined Condition: **supported**
 
-* 8. Stream Feature
+8\. Stream Feature
 
   * **supported**
 
-* 9. Security Considerations
+9\. Security Considerations
 
   * Currently, the security measures described in this section have not been
 implemented. It follows that `mod_amp`, in its current state, should only be
 enabled for servers/domains where user presence leaks are not a threat, i.e
 services where all users can see each other's presence by default.
 
-### Modifications
+## Modifications
 
 The following behaviour differs from or extends the guidelines provided in the XEP.
 
 * The action for the `deliver` condition with value `stored` is deferred until the message is stored by `mod_mam` or `mod_offline`.
 * The action for the `deliver` condition with value `direct` is deferred until the message is sent to the recipient's socket.
 
-### Server Processing Details
+## Server Processing Details
 
 When a message with AMP rules is being processed by the server, several system events may occur. For a given event, the rules are processed and each of them can get the *matched* or *undecided* status or, if the conditions are not met, it gets no status. If any rules get the *matched* status, the action for the first of them is performed. After that, the rule list is filtered so that only the *undecided* ones are left in the message, as they may be matched later.
 

doc/modules/mod_auth_token.md

@@ -1,4 +1,4 @@
-### Module Description
+## Module Description
 
 This module implements handling of tokens in an OAuth-like authentication scheme. 
 It provides services necessary to:
@@ -13,21 +13,21 @@ It provides services necessary to:
 The module itself does not implement protocol related details - these are implemented in `cyrsasl.erl`.
 Generation of keys necessary to sign binary tokens is delegated to module `mod_keystore.erl`.
 
-### Options
+## Options
 
-#### `modules.mod_auth_token.validity_period`
+### `modules.mod_auth_token.validity_period`
 * **Syntax:** Array of TOML tables with the following keys: `token`, `value`, `unit` and following values: {token = `values: "access", "refresh", "provision"`, value = `non-negative integer`, unit = `values: "days", "hours", "minutes", "seconds"`}.
 * **Default:** `[{token = "access", value = 1, unit = "hours"}, {token = "refresh", value = 25, unit = "days"}]`
 * **Example:** `[{token = "access", value = 13, unit = "minutes"}, {token = "refresh", value = 13, unit = "days"}]`
 
 Validity periods of access and refresh tokens can be defined independently.
 Validity period configuration for provision tokens happens outside the module since the server does not generate provision tokens - it only validates them.
 
-#### Required keys
+### Required keys
 
 To read more about the keys MongooseIM makes use of, please refer to [mod_keystore](mod_keystore.md) documentation.
 
-### Token types
+## Token types
 
 Three token types are supported:
 
@@ -49,7 +49,7 @@ Three token types are supported:
   Using a provision token to create an account (and inject VCard data) is done similarly to other token types, i.e. by passing it as payload for the X-OAUTH mechanism.
   The XMPP server has no way of tracking and revoking provision tokens, as they come from an outside source.
 
-### Token serialization format
+## Token serialization format
 
 All tokens (access, refresh, provision) are to be exchanged as *Base64 encoded* binary data.
 Serialization format of the token before encoding with Base64 is dependent on its type:
@@ -85,7 +85,7 @@ For example (these tokens are randomly generated, hence field values don't make
 
 To request access and refresh tokens for the first time a client should send an IQ stanza after they have successfully authenticated for the first time using some other method.
 
-### Token response format
+## Token response format
 
 Requested tokens are being returned by the server wrapped in IQ stanza with the following fields:
 
@@ -107,7 +107,7 @@ Example response (encoded tokens have been truncated in this example):
 
 Once a client has obtained a token, they may start authenticating using the `X-OAUTH` SASL mechanism when reaching the authentication phase of an XMPP connection initiation.
 
-### Login with access or refresh token
+## Login with access or refresh token
 
 In order to log into the XMPP server using a previously requested token, a client should send the following stanza:
 
@@ -130,7 +130,7 @@ cmVmcmVzaAGQ1Mzk1MmZlYzhkYjhlOTQzM2UxMw==
 
 The above response is to be expected unless the refresh token used is expired or there were some problems processing the key on the server side.
 
-### Token revocation using command line tool
+## Token revocation using command line tool
 
 Refresh tokens issued by the server can be used to:
 
@@ -152,8 +152,7 @@ Moreover, an access token still kept on a compromised device can be used to esta
 To alleviate rerequesting tokens by the user, an operator can use `mod_admin` extension allowing to terminate the user's connection.
 Access token validity can't be sidestepped right now.
 
-
-### Example configuration
+## Example configuration
 
 ```toml
 [modules.mod_auth_token]

doc/modules/mod_blocking.md

@@ -1,11 +1,13 @@
-### Module Description
+## Module Description
 This module implements [XEP-0191: Blocking command](http://xmpp.org/extensions/xep-0191.html).
 The extension allows blocking the whole communication with a user (or a group of users) with a single command. 
 The protocol is much simpler than privacy lists.
 
-### Options
+## Options
 
-### Example Configuration
+none
+
+## Example Configuration
 ```toml
 [modules.mod_blocking]
 ```

doc/modules/mod_bosh.md

@@ -1,43 +1,43 @@
-### Module Description
+## Module Description
 This module implements [XEP-0206: XMPP Over BOSH](http://xmpp.org/extensions/xep-0206.html) (using [XEP-0124: Bidirectional-streams Over Synchronous HTTP (BOSH)](http://xmpp.org/extensions/xep-0124.html)),
  allowing clients to connect to MongooseIM over regular HTTP long-lived connections.
 
 If you want to use BOSH, you must enable it both in the `listen` section of 
 `mongooseim.toml` ([Listener Modules](../advanced-configuration/listen.md))
  and as a module.
 
-### Options
+## Options
 
-#### `modules.mod_bosh.inactivity`
+### `modules.mod_bosh.inactivity`
  * **Syntax:** positive integer or the string `"infinity"`
  * **Default:** `30`
  * **Example:** `inactivity = 30`
 
 Maximum allowed inactivity time for a BOSH connection.
 Please note that a long-polling request is not considered to be an inactivity.
 
-#### `modules.mod_bosh.max_wait` 
+### `modules.mod_bosh.max_wait`
  * **Syntax:** positive integer or the string `"infinity"`
  * **Default:** `"infinity"`
  * **Example:** `max_wait = 30`
 
  This is the longest time (in seconds) that the connection manager will wait before responding to any request during the session.
 
-#### `modules.mod_bosh.server_acks`
+### `modules.mod_bosh.server_acks`
  * **Syntax:** boolean
  * **Default:** `false`
  * **Example:** `server_acks = true`
 
 Enables/disables [acks](http://xmpp.org/extensions/xep-0124.html#ack-request) sent by server.
 
-#### `modules.mod_bosh.maxpause`
+### `modules.mod_bosh.maxpause`
  * **Syntax:** positive integer
  * **Default:** `120`
  * **Example:** `maxpause = 30`
 
 Maximum allowed pause in seconds (e.g. to switch between pages and then resume connection) to request by client-side.
 
-### Example Configuration
+## Example Configuration
 
 In the listener section:
 ```toml
@@ -50,7 +50,9 @@ In the listener section:
     host = "_"
     path = "/http-bind"
 ```
-In the module section:  
+
+In the module section:
+
 ```toml
 [modules.mod_bosh]
   inactivity = 20

doc/modules/mod_caps.md

@@ -1,27 +1,27 @@
-### Module description
+## Module description
 
 This module provides a presence-based mechanism for exchanging information about entity capabilities as defined in [XEP-0115](https://xmpp.org/extensions/xep-0115.html). Additionally, it filters out PEP messages that the recipient declared (in announced caps) being not capable of handling.  
 It is not this module's responsibility to intercept and answer disco requests routed between clients.
 
-### Options
+## Options
 
 This module expects two optional arguments that apply to [cache tab](https://github.com/processone/cache_tab):
 
-#### `modules.mod_caps.cache_size`
+### `modules.mod_caps.cache_size`
 * **Syntax:** non-negative integer
 * **Default:** `1000`
 * **Example:** `cache_size = 2000`
 
 The size of a cache_tab (the amount of entries) holding the information about capabilities of each user. 
 
-#### `modules.mod_caps.cache_life_time`
+### `modules.mod_caps.cache_life_time`
 * **Syntax:** non-negative integer or the string `"infinity"`
 * **Default:** `86`
 * **Example:** `cache_life_time = 30`
 
 Time (in seconds) after which entries will be removed.
 
-### Example Configuration
+## Example Configuration
 
 ```toml
 [modules.mod_caps]