Add way to select `where` to forward to

[oscgonfer]

We have now the ability to forward data via MQTT for those users that opt-in.
However, there are potentially various destinations where data will end in, with slightly varying formats. This currently happens on two projects, where can't find an agreement as they have differing architectures.

There is a possibility to make custom remapping for specific project via EMQX rules.

This allows us to delegate on the broker and it's scalability to perform these tasks very efficiently.

There is, however, one caveat. The resulting message is republished on a custom topic, which needs to be kept in the form of:

/forward/<secret>/device/<device-id>/readings/<sub-topic>/#

So that we can comply with the API authorisation mechanism we already have implemented. This means that, to be able to keep "dropped-messages" to 0, we need to know where to map device X to topic Y, and people listen to them, and avoid remapping everything, as this would result on a massive amount of topics.

For traceability, this is currently implemented on device 18447 for testing, and you can subscribe to it on each sensor id after citiobs subtopic, so:

• Topic is:

${topic}/citiobs/${component.sensor.id}

• Payload is:

{
  "sensor"=${component.sensor},
  "data"=${component.readings},
  "hardware"=${payload.hardware},
  "name"=${payload.name},
  "description"=${payload.description},
  "location"=${payload.location},
  "owner"=${payload.owner.username},
  "policy"=${payload.data_policy}
}

I would suggest we have a place where a predefined list of "destinations" can be selected, and added as a tag on the device, which can be then used for EMQX to make the forwarding properly.

[oscgonfer]

Another consideration. Let's imagine that under the current schema, a data aggregator in this mode has to subscribe to many users that generate data streams (or communities). Ideally, this where could be associated with a user (or users) who, in the future, could have an endpoint where they can retrieve a list of user ids for that where.

This is a weird workflow, but that would solve a complicated management of streams. This could also be solved partially by communities, but not all of them are together.

@timcowlishaw