(Add option to) forward command & control message to all available gateways

[calohmn]

Currently, when an incoming command & control message has multiple possible target gateways (given by all currently connected/subscribed via gateways of the command target device), then the "lastKnownGateway" information is used for deciding to which gateway to forward the message to.

However, if a device only ~~randomly~~ sporadically sends telemetry/event messages and thereby only ~~randomly~~ sporadically updates the lastKnownGateway information, and if the device switches from one gateway to the other more often, then this information isn't necessarily useful and wouldn't prevent the command from potentially reaching a gateway that the device isn't connected to at that moment.

I think an alternative could be to just forward a command to all available (i.e. connected and subscribed) target gateways.

Then we could skip updating the lastKnownGateway information, which is rather expensive since it is done for every telemetry/event message delivery.

The decision on which disposition (accepted, released, rejected) to update the command delivery with, could then be done by taking the first "accepted" outcome that has come back, or, if there is none, using either "rejected" or "modified" if one was received, or using "released" instead.

The downside of this approach would be increased traffic if there are many gateways of a device connected/subscribed at the same time. Therefore we might consider making this kind of behaviour configurable.

[sophokles73]

I assume that by randomly sends messages you mean sporadically sends messages? If so, then updating the lastKnownGateway shouldn't be a big deal anyway, should it?