Enable Response/Error Mapping in Smart Rest via MQTT

On behalf of TT-Control, I'd like to create the below feature request:

# Feature Request - Enable Request/Response Mapping in Smart Rest via MQTT

## Requirement

TT-Control implemented an Agent in Smart Rest 1 via Mqtt a while ago. They have the requirement to not lose any data, specifically they need to be able to map and react to any error that happened for a Smart Rest request. They run in below issues with this requirement.

## Problem Description

With Smart Rest via MQTT, we provide the option to define request- and response templates. F.e. you can define in Smart Rest 1 the request/response template to query the list of pending operations for a device, the platform will respond the according list. Same goes for Smart Rest 2, wher you can also define response templates.

What happens is that a client sends a request on a specific request-topic (for Smart Rest it would be s/us) and receive somewhen later the response on s/ds. With a "clever" template design you are able to map requests of a specific type. However, there's no option available to map the specific response message itself to its original request. This becomes an issue in two scenarios:

a) With the parallel execution of messages, potentially with the same type (which is the case on TT-Controls side)

b) In case of errors on platform-side

I'd like to highlight b) as the situation gets even worse on errors as there is not even a reference to the original request type for errors -> so also the workaround to map it on type-level is not possible anymore. There's situations (a MongoDB error, an overload scenario, someone deleted the device, ...) where client does receive multiple errors for multipe requests in parallel. TT-Controls agent needs to have this mapping as their agent buffers original requests to do proper error handling in case of issues.

Please note, in the option "JSON via MQTT" we have the original messageId available in the error description. Shouldn't we have this available for Smart Rest as well? We could harmonize this and provide the option to map errors messages via Smart Rest not just for JSON via MQTT but also for Smart Rest via Mqtt.

## Potential Improvement

A potential improvement could be to parametrize the topic with an own device-managed message id. E.g.

- If a client sends a request on e.g. "s/us?messageId=12", the response/error is sent to "s/ds/12"

- If there's no messageId passed in the request, everything stays as is

This way the device integrator could pass an optional paramter to realize a asynchronous request/response pattern and would be able to map each and every response/error to its origin.

Another option could be to support MQTT v5, which is supporting request/response patterns via "response-topics" (https://www.hivemq.com/blog/mqtt5-essentials-part9-request-response-pattern/).