fix anchors for due to documentation changes

- fixed blog posts
- fixed open-api docs

Author: kalinkostashki

documentation/src/main/resources/_posts/2018-02-07-milestone-announcement-020-M1.md

@@ -16,7 +16,7 @@ The Ditto team is proud to announce the next milestone release.
 Have a look at the Milestone [0.2.0-M1 release notes](release_notes_020-M1.html). 
 
 The main changes are
-* being able to [search in namespaces](httpapi-search.html#query-parameters) which can speed up search queries when applied
+* being able to [search in namespaces](httpapi-search.html#examples) which can speed up search queries when applied
   to a large population of digital twins
 * the enhancement of our [Feature entity](basic-feature.html) by [Definitions](basic-feature.html#feature-definition)
   which lays the foundation for using Features in a typesafe way (later by enforcing the schema with the help of an

documentation/src/main/resources/_posts/2018-12-05-example-command-and-control.md

@@ -193,7 +193,7 @@ The request is now open to receive a command for 60 seconds before it is termina
 
 ### Send a Ditto message
 
-Now we can use the [Ditto Messages API](protocol-specification-things-messages.html#using-the-messages-api) to send a 
+Now we can use the [Ditto Messages API](protocol-specification-things-messages.html#examples) to send a 
 message to the device waiting for a command: 
 ```bash
 curl -i -X POST 'https://ditto.eclipseprojects.io/api/2/things/org.eclipse.ditto:teapot/inbox/messages/brew?timeout=60' \

documentation/src/main/resources/_posts/2021-09-29-kafka-connectivity.md

@@ -18,7 +18,7 @@ The time has come to support consuming as well.
 A Kafka connection behaves slightly different from other consuming Connections in Ditto.  
 The following aspects are special:
 * [Backpressure by using acknowledgements](connectivity-protocol-bindings-kafka2.html#quality-of-service)
-* [Preserve order of messages on redelivery due to failed acknowledgements](connectivity-protocol-bindings-kafka2.html#backpressure-by-using-acknowledgements)
+* [Preserve order of messages on redelivery due to failed acknowledgements](connectivity-protocol-bindings-kafka2.html#backpressure-via-acknowledgements)
 * [Expiry of messages](connectivity-protocol-bindings-kafka2.html#message-expiry)
 
 ### Scalability

documentation/src/main/resources/_posts/2021-11-03-oauth2.md

@@ -82,7 +82,7 @@ placeholder. The unencoded headers and body are as follows.
 
 # Create the connection
 
-[Create a connection](connectivity-manage-connections.html#create-connection)
+[Create a connection](connectivity-manage-connections.html#create-a-connection)
 publishing twin events to the event publishing webhook using OAuth2 credentials.
 The `tokenEndpoint` field is set to the access token webhook.
 

documentation/src/main/resources/_posts/2021-12-20-http-live-channel.md

@@ -11,21 +11,21 @@ toc: true
 ---
 
 The upcoming release of Eclipse Ditto **version 2.3.0** will support sending commands via the HTTP API 
-directly to devices using the [live channel](protocol-twinlive.html#live) by just adding the `channel=live` 
-query parameter to the same HTTP API request which would target the [twin](protocol-twinlive.html#twin).
+directly to devices using the [live channel](protocol-twinlive.html#live-channel) by just adding the `channel=live` 
+query parameter to the same HTTP API request which would target the [twin](protocol-twinlive.html#twin-channel).
 
 ## HTTP Live channel
 
-Ditto supports sending all kind of [Thing commands](protocol-specification-things.html#commands) via
+Ditto supports sending all kind of [Thing commands](protocol-specification-things.html#create-and-modify-commands) via
 the `live` channel directly to devices.
 When sending a `live` command to  a device, the device is responsible for sending a correlated and correct response 
 in [Ditto Protocol](protocol-overview.html).
 
 Ditto supports two types of `channel`s for communication.
 
-* [twin](protocol-twinlive.html#twin): The default value of the channel parameter is `twin` 
+* [twin](protocol-twinlive.html#twin-channel): The default value of the channel parameter is `twin` 
   to communicate with the persisted **twin** representation.
-* [live](protocol-twinlive.html#live): The `channel` parameter can be changed to `live` 
+* [live](protocol-twinlive.html#live-channel): The `channel` parameter can be changed to `live` 
   to communicate with the real device.
 
 {% include note.html content="In order to use the live channel, the device receiving live commands must be able to understand

documentation/src/main/resources/_posts/2021-12-22-live-channel-condition.md

@@ -10,11 +10,11 @@ sidebar: false
 toc: true
 ---
 
-After the added option to target the [live channel](protocol-twinlive.html#live) by adding the `channel=live` to HTTP
+After the added option to target the [live channel](protocol-twinlive.html#live-channel) by adding the `channel=live` to HTTP
 requests (see also [blog post about "HTTP live channel"](2021-12-20-http-live-channel.html)), Eclipse Ditto 
 **version 2.3.0** will in addition support to define a 
 [live channel condition](basic-conditional-requests.html#live-channel-condition), which, when evaluating to `true`, 
-will retrieve data from a device via the live channel, or fall back to the persisted [twin](protocol-twinlive.html#twin) 
+will retrieve data from a device via the live channel, or fall back to the persisted [twin](protocol-twinlive.html#twin-channel) 
 otherwise.
 
 {% include note.html content="In order to use the live channel, the device receiving live commands must be able to understand
@@ -72,15 +72,15 @@ GET /api/2/things/my.namespace:my-polling-device-1/features/temperature/properti
 ```
 
 The specified `live-channel-condition` will evaluate to `true`, meaning that the retrieve is transformed to a 
-[live command](protocol-twinlive.html#live) and sent to the device, e.g. connected via a 
+[live command](protocol-twinlive.html#live-channel) and sent to the device, e.g. connected via a 
 [managed connection](basic-connections.html).  
 Upon receiving the "live retrieve" at the device, the device can create a command response correlated with the same
 `correlation-id` and send it back to Ditto with the current value.  
 This value is then returned as result of the `GET`, the HTTP response header `channel` will indicate that the data was
 sent by the device by having the value `live`.
 
 If the device does not answer with a correctly correlated response within the given `timeout`, the request will fall back
-to the [twin](protocol-twinlive.html#twin) channel, retrieving the data from the last known persisted temperature value 
+to the [twin](protocol-twinlive.html#twin-channel) channel, retrieving the data from the last known persisted temperature value 
 in the twin managed by Ditto.  
 The HTTP response header `channel` will indicate that the data was received by the persisted twin by having the value 
 `twin`.

documentation/src/main/resources/_posts/2022-01-21-release-announcement-230.md

@@ -12,11 +12,11 @@ toc: false
 
 The Eclipse Ditto teams announces availability of Eclipse Ditto [2.3.0](https://projects.eclipse.org/projects/iot.ditto/releases/2.3.0).
 
-It contains mainly new features around the Ditto ["live" channel](protocol-twinlive.html#live) which can be used to 
+It contains mainly new features around the Ditto ["live" channel](protocol-twinlive.html#live-channel) which can be used to 
 directly interact with devices.
 
 Such live commands may now be easily [created via the HTTP API](2021-12-20-http-live-channel.html) - and in addition
-a conventional API call targeting the persisted [twin](protocol-twinlive.html#twin) may now be automatically converted
+a conventional API call targeting the persisted [twin](protocol-twinlive.html#twin-channel) may now be automatically converted
 to a live command, based on a passed [live channel condition](2021-12-22-live-channel-condition.html).
 
 With that, we are proud that we now can provide a really powerful addition to Ditto's "Digital Twin pattern":

documentation/src/main/resources/_posts/2023-10-09-ditto-benchmark.md

@@ -220,7 +220,7 @@ Example message:
 device_id:org.eclipse.ditto:test-thing-1,ditto_message:y!{"topic":"org.eclipse.ditto/test-thing-1/things/twin/commands/modify","path":"features/coffee-brewer/properties/brewed-coffees","value":"10"}
 ```
 
-In this scenario, connectivity service is used to create a ditto kafka connection, which reads messages from the provided topic, maps them to a ditto modify command and forwards it to things service. The things service then executes mongodb update query and generates the [thing modified event](protocol-specification-things-create-or-modify.html#event), which is pushed to the MMock service instance via an HTTP Push connection. Also, the kafka connection is configured with [qos=1](connectivity-protocol-bindings-kafka2.html#quality-of-service), which means if there is no acknowledgement that the thing is persisted, the operation will be retried.
+In this scenario, connectivity service is used to create a ditto kafka connection, which reads messages from the provided topic, maps them to a ditto modify command and forwards it to things service. The things service then executes mongodb update query and generates the [thing modified event](protocol-specification-things.html#create-or-modify-a-thing), which is pushed to the MMock service instance via an HTTP Push connection. Also, the kafka connection is configured with [qos=1](connectivity-protocol-bindings-kafka2.html#quality-of-service), which means if there is no acknowledgement that the thing is persisted, the operation will be retried.
 
 The HTTP Push connection looks like the following:
 
@@ -354,7 +354,7 @@ Scaling connectivity instance and changing our connection to have **clientCount*
 
 ### Device live messages(commands)
 
-This scenario executes HTTP POST requests to ditto's [live channel](protocol-twinlive.html#live). An HTTP Push connection is subscribed for them and in turn pushes to a MMock instance that acts as a 'dummy' device receiver of live messages/commands and simply responds with pre-configured ditto response.
+This scenario executes HTTP POST requests to ditto's [live channel](protocol-twinlive.html#live-channel). An HTTP Push connection is subscribed for them and in turn pushes to a MMock instance that acts as a 'dummy' device receiver of live messages/commands and simply responds with pre-configured ditto response.
 
 The HTTP POST request looks like the following:
 

documentation/src/main/resources/openapi/ditto-api-2.yml

@@ -4247,7 +4247,7 @@ paths:
         No special permission is required to issue a claim message.
 
         ### Example
-        See [Claiming](https://www.eclipse.dev/ditto/protocol-specification-things-messages.html#sending-and-handling-claim-messages) concept in detail and example in GitHub.
+        See [Claiming](https://www.eclipse.dev/ditto/protocol-specification-things-messages.html#claim-messages) concept in detail and example in GitHub.
         However, in that scenario, the policy should grant you READ and WRITE permission on
         the "message:/" resource in order to be able to send the message and read the response.
         Further, the things-client which handles the "claim" message, needs permission to change the policy itself

documentation/src/main/resources/openapi/sources/paths/messages/inbox-claim.yml

@@ -38,7 +38,7 @@ post:
     No special permission is required to issue a claim message.
 
     ### Example
-    See [Claiming](https://www.eclipse.dev/ditto/protocol-specification-things-messages.html#sending-and-handling-claim-messages) concept in detail and example in GitHub.
+    See [Claiming](https://www.eclipse.dev/ditto/protocol-specification-things-messages.html#claim-messages) concept in detail and example in GitHub.
     However, in that scenario, the policy should grant you READ and WRITE permission on
     the "message:/" resource in order to be able to send the message and read the response.
     Further, the things-client which handles the "claim" message, needs permission to change the policy itself