feat: send email notifications for storage quota usage

[adamalton]

Fixes #851.

This is an overall feature PR for #851, bringing together the work done in these sub-tasks:

• feat: storage quota notifications #1156 (which implements the core of this feature)
• feat: admin emails for storage #1264 (which implements Storage limit - Notify admins of users approaching/over storage limit #1189)
• feat: mailchimp email service #1282 (which implements Storage limit - Add MailChimp email service #1153)
• feat: add github workflow cron job for storage limit email alerts #1248 (which implements Storage limits - automate the email job #1193)

Now that those sub-tasks are done and merged to this branch, this is ready to be reviewed and merged as a complete feature. Note that potential follow-up improvements for this feature are listed in #1283.

Some of the requirements in the #851, are already in main or are part of admin.

Specifically:

• Manual interface to set a restriction flag (in admin.storage)
• Set a new user tag with storage in admin.storage
• Implement restriction on all APIs/interface

Outstanding discussion

There's an outstanding question of how often we want to run the cron job. Running it more frequently won't send the emails more frequently (each email type has its own frequency limit, so it will only be sent as often as necessary), but if we only run the cron every 24 hours then there's potentially up to a 24 hour delay between a user hitting a threshold and them receiving an email about it. If that delay is too long then we should run the cron more frequently. That needs to be balanced with not hammering the platform/DB too much (although I don't foresee a real issue here). My proposal is to increase the frequency to every 6 hours.
Original comment here

Oustanding tasks

• We need the API key from the Mailchimp account adding to the GitHub secrets as MAILCHIMP_API_KEY. I don't think any of us (Potato) have got access to the right stuff in GitHub to be able to do this.
• Testing this on staging before we deploy to production. (See below.)
• Enabling the cron job for production as well as staging in the GitHub workflow config file and update cron schedule to run every 6 hours.

Testing this

Before we release this to prod, we should test it on staging. The plan for this is:

1. Deploy to staging. (We can actually deploy to prod as well if we want, as the cron job config is only set up to run it on staging at the moment - see above.)
2. Create some user accounts for ourselves and upload/pin some files.
3. Use admin.storage to set our quotas to something low enough to reach the 75%/80%/etc limit.
4. Run the cron job manually via the GitHub UI (see instructions).
5. Reduce our quotas again so that we go over the limit.
6. Manually trigger the cron again.
7. Check that we’ve received the right emails and that the list of users over their quota has been sent to support@web3.storage.

[hugomrdias]

LGTM just left one inline comment

im good with cron running every 6 hours.

Are we just missing an Mailchimp key to test this in staging ?

[hugomrdias]

can't we just use fetch here to call the api instead of requiring the full SDK, it seems to be just this code https://github.com/mailchimp/mailchimp-transactional-node/blob/master/src/ApiClient.js#L70-L104 running