Pin markdownlint-cli version and apply fixes (#2320)

* Pin markdownlint-cli version

* Apply markdownlint fixes

Makefile

@@ -54,7 +54,7 @@ markdown-toc:	$(MARKDOWN_TOC)
 	done
 
 $(MARKDOWN_LINT):
-	npm install markdownlint-cli
+	npm install markdownlint-cli@0.31.0
 
 .PHONY: markdownlint
 markdownlint:	$(MARKDOWN_LINT)

specification/metrics/semantic_conventions/http-metrics.md

@@ -96,7 +96,7 @@ path.
 * `http.scheme`, `net.peer.ip`, `net.peer.port`, `http.target`
 
 **[2]** For server metric attributes, `http.url` is usually not readily available on the server side but would have to be assembled in a cumbersome and sometimes lossy process from other information (see e.g. <https://github.com/open-telemetry/opentelemetry-python/pull/148>).
-It is thus preferred to supply the raw data that *is* available.
+It is thus preferred to supply the raw data that _is_ available.
 Namely, one of the following sets is RECOMMENDED (in order of usual preference unless for a particular web server/framework it is known that some other set is preferable for some reason; all strings must be non-empty):
 
 * `http.scheme`, `http.host`, `http.target`

specification/trace/semantic_conventions/http.md

@@ -28,7 +28,7 @@ HTTP spans MUST follow the overall [guidelines for span names](../api.md#span).
 Many REST APIs encode parameters into URI path, e.g. `/api/users/123` where `123`
 is a user id, which creates high cardinality value space not suitable for span
 names. In case of HTTP servers, these endpoints are often mapped by the server
-frameworks to more concise _HTTP routes_, e.g. `/api/users/{user_id}`, which are
+frameworks to more concise *HTTP routes*, e.g. `/api/users/{user_id}`, which are
 recommended as the low cardinality span names. However, the same approach usually
 does not work for HTTP client spans, especially when instrumentation is provided
 by a lower-level middleware that is not aware of the specifics of how the URIs

specification/trace/semantic_conventions/messaging.md

@@ -178,7 +178,7 @@ For message consumers, the following additional attributes may be set:
 | `process` | process |
 <!-- endsemconv -->
 
-The _receive_ span is be used to track the time used for receiving the message(s), whereas the _process_ span(s) track the time for processing the message(s).
+The *receive* span is be used to track the time used for receiving the message(s), whereas the *process* span(s) track the time for processing the message(s).
 Note that one or multiple Spans with `messaging.operation` = `process` may often be the children of a Span with `messaging.operation` = `receive`.
 The distinction between receiving and processing of messages is not always of particular interest or sometimes hidden away in a framework (see the [Message consumption](#message-consumption) section above) and therefore the attribute can be left out.
 For batch receiving and processing (see the [Batch receiving](#batch-receiving) and [Batch processing](#batch-processing) examples below) in particular, the attribute SHOULD be set.
@@ -189,7 +189,7 @@ Instead span kind should be set to either `CONSUMER` or `SERVER` according to th
 
 #### RabbitMQ
 
-In RabbitMQ, the destination is defined by an _exchange_ and a _routing key_.
+In RabbitMQ, the destination is defined by an *exchange* and a *routing key*.
 `messaging.destination` MUST be set to the name of the exchange. This will be an empty string if the default exchange is used.
 
 <!-- semconv messaging.rabbitmq -->