Ensures email alert is only sent once to the Email Alert API

https://www.pivotaltracker.com/story/show/79010378

In order to prevent the unlikely-but-possible case where a message is delivered multiple times
on the queue for a single change to a piece of content, we set a key in Redis with an agreed expiry time of three months. If a lock key exists for a message, the Email Alert API is not notified.

Authored by @dp6ai and @pedrosmmoreira.
If this fails (eg, email-alert-api has downtime for a bit), the lock will be left set here.  If we then try manually replaying the messages to send emails for the period when gov-delivery was down, we'd like the emails to be sent again, but the lock will just make them be thrown away.

I think we should assume that any exceptions raised by the email api client mean that the email was not sent - ideally, we'd try sending them again automatically (with some kind of backoff), but a good start would be to log the failure to errbit, and to remove the lock so that replaying recent messages would cause the emails to be sent.

Also, we should log something when the lock is already held, so that we can get some idea how often that's happening.

Finally, I'm not sure why we need to set the lock expiry after sending the alert.  If our app dies before setting the expiry, that particular entry will never expire.  I think we should be able to set it immediately after calling "setnx" (ideally in a "transaction" (see http://redis.io/topics/transactions) so that there's no chance the expire doesn't get set).

TL;DR: I suggest:
 - log when the lock is already held.
 - set the expiry at the same time as checking the lock, using a "MULTI-EXEC" transaction.
 - wrap the call to send the email in a try-catch block: if any exception is raised, remove the redis lock, so that replaying the failed email will send it again.

We could happily leave automatic retrying of failed sends to another day.