Implement alert mechanism

[niconoe]

Large task, to be done later based on user's feedback. First ideas in #9, collecting ideas and requirement here

1. Bram confirmed that people will need to draw their own polygons for the geographic selection, but also that having MULIPOLYGON (= for a single alert) would be great, and also shapefile(?) upload (some users already have a shapefile with the multiple tiny zones they manage).
2. Bram: observers contact information will be a problem: often needed for management, but some people don't want to share, and privacy/RGPD must be respected AND it's not a good fit for GBIF. How to reconcile all this?
3. Bram: e-mail frequency should be configurable: you want higher frequency for animals than plants (+ user personal preferences).

[damianooldoni]

As we discussed during the meeting, I add some proposed solutions:

1. some shapefiles could be added to this repository as we did for the three river basins
2. the GDPR problem is not really at GBIF level: we will provide the link to the raw observation webpage (iNaturalist, waarnemingen.be, observations.org). All details the observer want to share are there, the rest is not something solvable, I think
3. email notification frequency should be set up at alert level, not at user level

[niconoe]

(we also added notes for that in #9: I'll have to merge/clean those notes).

Good thing is: the general mechanism appears solid to the stakeholder's we've talked with, both internally (OSCIBIO, Bram, ...) and externally (Etienne & co).

[niconoe]

Update: I will soon implement the first version of this major feature. We need a lot of other systems in place for it, though.

Requirements:

• basic user management
• stable identifier mechanism for the occurrences (between data imports)
• ability to send e-mails
• per-species filtering
• per-area filtering (Proper polygon data store + related code (API, filtering, ...) #66)
• rock-solid data import (see Test suite for the occurrence import mechanism #40 and Make occurrence import process atomic #62)
• seen/unseen status for observations (per user) - done, but lacks unit tests
• API: per-status (read/unread) observations filtering: done, but needs: polishing SQL query in maps.py
• maintenance mode

Feature:

• "My alerts" page
• Add alert page
• Edit alert page
• See alert details (observations)
• E-mail notifications
• Show "unseen observations counter" for each alert, on "My alerts" page.

[niconoe]

Update: feature implemented, but we need good tests for the email notifications, for example:

• That the send_alert_notifications_email command does the right thing
• That Alert.email_should_be_sent_now follows the correct business logic
• That Alert.send_notification_email log errors and save the timestamp
• That the user-facing page shows the time of last email sent

[niconoe]

Since a basic alert/notification mechanism is now in place, I suggest closing this issue and extracting the few remaining points/ideas to smaller, more actionable issues.