[WIP] [TTN] Add experimental TTS/TTN HTTP Webhook forwarder

[amotl]

About

Following up on GH-81, this patch aims to bring a multi-tenant addressing scheme to TTN/TTS data acquisition, like, everything relevant we discussed at ¹.

Footnotes

1. https://community.hiveeyes.org/t/tts-ttn-daten-an-kotori-weiterleiten/1422 ↩

[amotl]

Regarding our discussion over at TTS-/TTN-Daten an Kotori weiterleiten ff., whether to use a prefix like /apittn, or a suffix like /data-ttn, for signalling that it's a request from TTN, it looks like I've proposed a third variant here, using an infix like /ttn after the <realm> component. Interesting!

/cc @thiasB

[amotl]

The reason I don't fancy the prefix variant too much is that the addressing slot at the very front of the URL is usually managed by infrastructure outside of Kotori. For example, we are using Nginx to dispatch exactly two prefix routes to Kotori, that is /api, and /api-notls. In order to keep that interface concise and lean, I think we should not use this particular addressing slot for other purposes than the two main entrypoints it is currently used for.

Thinking more about the topic in general, I am leaning towards the idea that signalling special decoding needs should actually be pushed to the end of the URL instead, so maybe we will finally introduce query parameters for that purpose, instead of trying to squeeze those metadata into the URL path itself?

In this case, we would not need any special forwarding component with an accompanying pattern-based forwarding rule configuration like outlined above, but would just signal additional information to the (passive) decoder component instead, which would be able to take two routes of dispatching, based on this information:

1. Apply decoding based on the "device_id in URL" variant.
2. Apply decoding based on the "device_id in Payload" variant.

On the other hand, it may be better to let the operator decide, and configure TTN capabilities on an existing channel group by adding a special flag to the configuration snippet. I am not yet 100% sure about that detail, this is why I am bouncing on an off about it. Personally, in order to give more power to the users, I am leaning towards the hassle-free "works out of the box" variant, which does not need any special configuration by operators at all.
I am not sure if we can achieve this.

[amotl]

I've diverted the discussion to GH-133. Thanks for listening.

[amotl]

With, for example, baseurl=/mqttkit-1/ttn, and device_id=itest-foo-bar, a full URL would boil down to:

https://daq.example.org/api/mqttkit-1/ttn/itest-foo-bar/uplinks

It does not look too bad from the outside, right? In this case, we omit the device's <realm> address component from its device_id identifier, to make it a bit shorter, and to better reflect the fact that it is only those address components the users may change on their own behalves.

In TTN parlance, using {/devID} to interpolate the device_id into the URL, that would mean to use a configuration setting like:

https://daq.example.org/api/mqttkit-1/ttn{/devID}/uplinks

realm  .....................^^
special identifier  ..................^^
device id (interpolated)  [1] ............^^
another special identifier [2] ...................^^

However, I still will need to explore if it can be implemented like that. Apparently, I got blocked by something the last time I was working on it, and then lost track of it.

[1] As we discussed already, there needs to be code which expands that device_id into a full topology path, like:

   mqttkit-1/ttn/itest-foo-bar
-> mqttkit-1/itest/foo/bar

I think the channel configuration snippet outlined above at #132 (review) tries to implement that transformation.

[2] I don't know yet, if this second special identifier will be needed for the final implementation. I don't favor it too much, but maybe it makes sense?

[amotl]

I've diverted the discussion to GH-133. Thanks for listening.

[amotl]

This patch has been superseded by GH-136 and GH-141.