oaeproject/Hilary — pull request #759 by simong (2014-01-30 23:51:57+00:00)
Title: Ensuring that the same mail doesn't get sent to the same user twice

Disclaimer: This is a stop-gap measure until email aggregation lands.

The email API will now try to get a lock (in Redis) each time it tries to send an e-mail.
It will lock on either:
* a new optional field called `id`
* if left unspecified it will lock on the mail headers (to + subject + txt body + html body)

This has a couple of effects:

1. Mass-emails on broken activity router
Although it's unlikely that the activity router gets stuck again, the mass flood of emails
is too annoying/upsetting to even have it as a remote possibility.
If it evers gets stuck in a loop on a particular seed again, it will no longer send out multiple emails for the entities involved in that activity

2. For activities the mail id = `to + activity.type + activity.published`
For activities that are generated in very quick succession, some emails might never get sent.
Imagine the following situation:
Alice uploads 50 content items and shares them (in the create request) with bob
If the files are small enough that 2 `content-create` activities get generated in the same millisecond there will be an identical mail ID for 2 activities.
This seems very unlikely, but it is a possibility

This is in relation to https://github.com/oaeproject/Hilary/issues/758