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 optional Twilio message operation to alerts script #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.