docs: Fix non-consecutive and incorrect header levels

docs/source/tutorials/debugging.md

@@ -1,6 +1,6 @@
-## Debugging actors
+# Debugging actors
 
-### Snactor
+## Snactor
 
 The snactor tool is used to debug your actors. You can execute actors
 and save their output, so that it can be consumed by other actors.
@@ -11,7 +11,7 @@ the --debug parameter which sets the environment variable to '1' when it is
 used. In that case, it enables the debug logging, so that any actor that logs
 to self.log.debug gets its output printed on the commandline.
 
-### PyCharm / rpdb
+## PyCharm / rpdb
 
 You can configure PyCharm to debug by pointing it to the snactor path and passing the arguments on the command line.
 The PyCharm debugger will also follow the child processes that are created by the snactor tool to execute the actor

docs/source/tutorials/dialogs.md

@@ -10,7 +10,7 @@ As an example we will change [IpResolver](messaging.md#creating-a-message-consum
 will decide which hostnames will be resolved.
 
 
-### Creating the dialog
+## Creating the dialog
 
 Import Dialog and MultipleChoiceComponent from leapp.dialog and leapp.dialog.components respectively.
 Create an instance of Dialog, specifying scope which is used to identify data in the answer file,
@@ -38,7 +38,7 @@ class IpResolver(Actor):
                                 description='No description'),)),)
 ```
 
-### Using the dialog and the answers
+## Using the dialog and the answers
 
 To pose a question that needs to be answered use get_answers method and pass the dialog containing the question.
 
@@ -70,7 +70,7 @@ def process(self):
         self.produce(ResolvedHostname(name=hostname, ips=ips))
 ```
 
-### Explaining the dialogs processing mechanism during the upgrade
+## Explaining the dialogs processing mechanism during the upgrade
 
 The upgrade itself, from the operator's point of view, consists of 3 distinct stages: preupgrade, remediate and upgrade.
 

docs/source/tutorials/messaging.md

@@ -1,12 +1,12 @@
-## Using messaging to send data between actors
+# Using messaging to send data between actors
 
 The Leapp framework uses messages to send data to other actors that are executed afterward.
 Messages are defined through the models declared [earlier](first-actor.md#creating-a-model). Actors can consume these messages and produce data based on their input.
 
 As an example, the actors consume Hostname messages, resolve IPs for those
 hostnames, and create the ResolvedHostname model to send a new type of message.
 
-### Creating the ResolvedHostname model
+## Creating the ResolvedHostname model
 
 Create the ResolvedHostname model by using the snactor tool.
 
@@ -39,7 +39,7 @@ fields.Nullable(fields.String())
 are required.
 
 
-### Creating a message consuming actor
+## Creating a message consuming actor
 
 Create a new actor that resolves the IPs for the hostnames:
 
@@ -96,7 +96,7 @@ class IpResolver(Actor):
             self.produce(ResolvedHostname(name=hostname.name, ips=ips))
 ```
 
-### Storing messages in the repository data for reuse
+## Storing messages in the repository data for reuse
 
 The `snactor` framework tool saves the output of actors as locally stored messages,
 so that they can be consumed by other actors that are being developed.
@@ -110,7 +110,7 @@ $ snactor run --save-output HostnameScanner
 The output of the actor is stored in the local repository data file, and it can be used
 by other actors. To flush all saved messages from the repository database, run `snactor messages clear`.
 
-### Testing the new actor
+## Testing the new actor
 
 With the input messages available and stored, the actor can be tested.
 
@@ -136,6 +136,6 @@ $ snactor run --print-output IpResolver
 ]
 ```
 
-#### Screencast
+### Screencast
 
 <asciinema-player src="_static/screencasts/messaging.json"></ascinema-player>