Allow external nodes to report

[relrod]

Right now mapview is a very "closed" system. It relies heavily on having a radio connected to a computer and having minimodem installed and running in the background to decode the data stream.

What would be nice if we ever get into HF telemetry and flights that go Really Far Away™ is if we could allow interested parties to set up a system to report in packets that they receive successfully. This method of reporting should probably remain optional, as localized flights might still want to run mapview the old way.

External reporting could work something like this:
A new program, mapview-api-server (probably based on the Scotty framework) would be created. Running this program spawns a server that listens on HTTP for requests to an endpoint, say /packet/<appid> via POST. <appid> would be replaced by the client who is sending the information. For example, dl-fldigi is able to send packets (I believe), and we should try to support that. So, people using that program could configure it to send data to http://api.nbp.noexc.org/report/dl-fldigi or similar. mapview-api-server would know how to decode the data from various appids.

Once the data was decoded, a row with the data would be added to a database and logged. We'd have to decide at what point to update the JSON file that mapview-send listens for changes to (e.g. we probably don't want to trust every update from every user and send it out), but once we decided to write out the file, mapview-send could function exactly as normal, with no changes.

[relrod]

With the way v3 is going to work, this will work differently, but is still something we should look at doing.

We'll need a tiny server-side component to record entries from people who contribute them and shove them in a database.

On the agent's/contributor's side, it'll look something like adding:

_mvCRCSuccessCallback = [report "https://telemetry.noexc.org/report"]

to their config file, and we'll provide a report callback in our stdlib of callback functions.

[relrod]

Along with this, since multiple users will need to reproduce our parsing setup and so on, we will probably want to have a noexc-nbp package on Hackage that contains a KD8ZRC.Flight.NBP# module for each flight. This module would export a function for the parser and any other functions and types that are essential but shouldn't be in our stdlib.

We'll also want to really make sure this is well tested and ensure that it doesn't change after a flight module is released to Hackage.