Implement schema for keeping tracking of expiration warning emails about boulder HOT 3 CLOSED

... expirationWarned INTEGER, lastWarnedAt DATETIME ... in the certificateStatus table (in your schema-updates fork) seems like it would work well.

The mailer could then have a fixed number of times to send warnings and a fixed interval (or variable based on expirationWarned) it should wait between sending emails which it can then check against and update the certificateStatus table to keep track of the stage, e.g. expirationWarned = 0 means no warning sent, expirationWarned = 1 means the first warning has been sent etc etc and lastWarnedAt is updated to the current datetime each time a email is sent.

from boulder.

No data would be lost if the table was constructed as a log of events, one for each email sent.

from boulder.

Fixed.

from boulder.