Markdown linter (#1309)

* Add markdown linting

- add linter default rules
- adapt rules to current code
- fix the code for linting to pass
- add CI check

fix #1243

* Fix markdown for Substrate
* Fix tooling install
* Fix workflow
* Add documentation
* Remove trailing spaces
* Update .github/.markdownlint.yaml

Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Fix mangled markdown/lists
* Fix captalization issues on known words

polkadot/roadmap/implementers-guide/src/node/disputes/README.md

@@ -4,12 +4,12 @@ If approval voting finds an invalid candidate, a dispute is raised. The disputes
 subsystems are concerned with the following:
 
 1. Disputes can be raised
-2. Disputes (votes) get propagated to all other validators
-3. Votes get recorded as necessary
-3. Nodes will participate in disputes in a sensible fashion
-4. Finality is stopped while a candidate is being disputed on chain
-5. Chains can be reverted in case a dispute concludes invalid
-6. Votes are provided to the provisioner for importing on chain, in order for
+1. Disputes (votes) get propagated to all other validators
+1. Votes get recorded as necessary
+1. Nodes will participate in disputes in a sensible fashion
+1. Finality is stopped while a candidate is being disputed on chain
+1. Chains can be reverted in case a dispute concludes invalid
+1. Votes are provided to the provisioner for importing on chain, in order for
    slashing to work.
 
 The dispute-coordinator subsystem interfaces with the provisioner and chain

polkadot/roadmap/implementers-guide/src/node/disputes/dispute-distribution.md

@@ -202,8 +202,8 @@ the dispute-coordinator already knows about the dispute.
 
 Goal 3 and 4 are obviously very related and both can easily be solved via rate
 limiting as we shall see below. Rate limits should already be implemented at the
-substrate level, but [are not](https://github.com/paritytech/substrate/issues/7750)
-at the time of writing. But even if they were, the enforced substrate limits would
+Substrate level, but [are not](https://github.com/paritytech/substrate/issues/7750)
+at the time of writing. But even if they were, the enforced Substrate limits would
 likely not be configurable and thus would still be to high for our needs as we can
 rely on the following observations:
 
@@ -282,10 +282,10 @@ well, we will do the following:
    to assume this is concerning a new dispute.
 2. We open a batch and start collecting incoming messages for that candidate,
    instead of immediately forwarding.
-4. We keep collecting votes in the batch until we receive less than
+3. We keep collecting votes in the batch until we receive less than
    `MIN_KEEP_BATCH_ALIVE_VOTES` unique votes in the last `BATCH_COLLECTING_INTERVAL`. This is
    important to accommodate for goal 5 and also 3.
-5. We send the whole batch to the dispute-coordinator.
+4. We send the whole batch to the dispute-coordinator.
 
 This together with rate limiting explained above ensures we will be able to
 process valid disputes: We can limit the number of simultaneous existing batches
@@ -312,8 +312,8 @@ of attackers, each has 10 messages per second, all are needed to maintain the
 batches in memory. Therefore we have a hard cap of around 330 (number of
 malicious nodes) open batches. Each can be filled with number of malicious
 actor's votes. So 330 batches with each 330 votes: Let's assume approximately 100
-bytes per signature/vote. This results in a worst case memory usage of 330 * 330
-* 100 ~= 10 MiB.
+bytes per signature/vote. This results in a worst case memory usage of
+`330 * 330 * 100 ~= 10 MiB`.
 
 For 10_000 validators, we are already in the Gigabyte range, which means that
 with a validator set that large we might want to be more strict with the rate limit or