Add support for diverting twin responses to another connection

[alstanchev]

Sometimes it is convenient the twin command responses to be sent to a destination, different from the source connection, where the commands orginated from.
The destination could be defined in a target of a separate (maybe dedicated) connection, in which the address and header mapping configuration of responses should be placed.

Implementation proposal:
In OutboundMappingProcessorActor of the source connection, the outbound messages (responses) could be diverted (or not, depending on the source configuration) to the target connection OutboundMappingProcessorActor by sending a pubSub message at a specialized for this purpose topic. OutboundMappingProcessorActor of the target connection should be subscribed to listen to messages on this topic and continue the flow with received messages.

[thjaeckle]

Hm, I understand the feature request.
Would you like to configure the connectionId then in the connection which should re-route the responses?
And as well a target (address?) of the connection to deliver responses to?

When implementing this, the approach must be really well thought through ..
E.g. in order to preserve and guarantee message order in case a connection is scaled > 1 "clients", the pub/sub would also have to apply a sharding based on e.g. thingId in order to always send messages responses for a thing "A" via the same connectivity instance.

Currently (as far as I remember) the responses are sent via Pekko to the original sender of a message (the original ActorRef is transported and preserved across the whole cluster).
For another sender than the actual sender to get the response instead, one could either:

• send back to the original sender first, then publish to another connection (simple, but inefficient - needs very likely another "hop" in the cluster for each response to deliver to another connection)
• inject "target connection to receive response" as sender of the Pekko message

[alstanchev]

The idea to change the sender and save a hop is really cool 👍 . We will look into if and how it could be done.

The connectionId of the rerouting connection maybe can be configured in the source connection as a header mapping. It is not clean to configure it as a some kind of special reply topic as in the inbound direction would be strange to try to access the targets to determine if a possible future response should be redirected. The Target config will be in the rerouting connection.
One fuzzy thing is how to configure the expectedResponseTypes (error, response, nack).
Maybe in the additional config of the replying connection. 🤔