Add script to post alerts to CoMapeo Cloud API

[rudokemper]

Goal

Closes #28.

Note

This code will not yet work in production, because it depends on digidem/comapeo-cloud#41 being merged and a new CoMapeo Docker image being published and deployed.

What I changed

• I added a comapeo_alerts script that performs the following tasks:
  • Retrieves alerts from the database.
  • Fetches alerts from the CoMapeo server.
  • Filters the database alerts against the alerts from the CoMapeo server to create a list of unposted alerts.
  • Posts the unposted alerts to the CoMapeo server.
• I added a e2e test that uses a mock CoMapeo server with GET and POST alerts endpoints, along with a server response fixture containing one existing alert, to simulate posting an unposted alert.

Notes

In implementing this, I sought fit to turn this into its own script apart from alerts_gcs to maintain clean code and ensure separation of concerns.

However, this approach introduces a sequence issue: when scheduled in production, this script should run after alerts_gcs has successfully ingested a new batch of alerts. While we can make a reasonable estimate of when to schedule this based on existing alerts_gcs run data across our Windmill instances, this approach is not deterministic and could encounter edge cases where an alerts_gcs run takes significantly longer than expected due to issues with GCP upstream.

This is further complicated by the fact we have a third operation in the sequence: #59 aims to send a Twilio message to recipients about new alerts. #59 adds this operation to the alerts_gcs script, but arguably, a message to recipients about new alerts should not be sent until both scripts have run: a CoMapeo user in the field can then know to synchronize, to see the new alerts on CoMapeo right away.

This leads me to think there are two options:

1. We have one giant script to rule them all, and chains a sequence of (a) alerts ETL, (b) post alerts to CoMapeo, (c) send Twilio message. In doing so we can separate the respective logic for each into separate files lacking a main function, but are imported into one that does.
2. We chain the scripts together using a Windmill Flow. But as mentioned in Add alerts_twilio script, and prepare alerts_gcs script for future usage in a Windmill Flow #59:

   This will increase the burden on our envisioned "operator" users, as they will need to understand an additional Windmill concept (and all that it entails—such as Directed Acyclic Graphs mentioned in the very first paragraph of the Windmill documentation explaining what a Flow is) and configure additional screens.

Opinions welcome.

[IamJeffG]

Thanks for the great "Notes" section. I would absolutely use a Windmill Flows.

Justification:
We have said that most users of Windmill will not be writing their own scripts, but instead just using scripts we've written in this Git repo: they would be pasting in inputs and maybe scheduling these canned scripts. The same goes for Flows. Windmill's UI exposes Flows as a first-class entity in almost the identical way it displays scripts: you click its name, paste your inputs, and click Run (or schedule). Most users will be able to use this repo's canned flows without ever reading the words "Directed Acyclic Graph".

Moreover, I think Flows may offer a pretty good solution (or workaround) to the code-reuse and package dependency questions discussed in #58.

If I were in your shoes, I'd:

1. merge this PR as you have it (its own script) - once the upstream dependency is in.
2. do a follow-up PR to define a flow that invokes both alerts_gcs and this script.

[rudokemper]

I will leave this PR open until digidem/comapeo-cloud#41 is merged.