D16752 was approximately the same thing but I think this is a little complicated -- both in general, and for recurring events. I'm also not really sure this should use the trigger system at all.

Using triggers for this is tricky because, among other things:

• recurring events are hard to attach triggers to;
• some events have different start times for different users;
• it would be nice to group all of your events together if you have several events starting at the same time.

Maybe a better approach is to just run a check every ~5 minutes for events starting in the next ~15 minutes, do any notifying we need to do, and then mark who we notified about what somewhere (for "All Day" events, we need to notify west-coast attendees and east-coast attendees at different times, and these notifications probably aren't useful anyway; better would be including them in a 6AM "your schedule today" sort of digest, perhaps).

So I think this looks like:

• New storage of <parentPHID, instanceStartUTC, userPHID, didNotifyEpoch>.
  • (Maybe this is also a cache of start times to make the scanning cheaper? We need to look ~24 hours ahead to deal with timezones.)
• New TriggerDaemon phase for scanning Calendar events.
• When we hit a user to notify, check for other stuff in the next ~hour to notify them of? Maybe v2?
  • Fancier handling for all-day, etc (v2/v3)?
• When we deliver a notification, mark it in the table. Don't deliver notifications if they're marked.
• Keep a cursor somewhere? Does that need a new table too? Maybe just keep it in-process and start it at ~15m ago, since un-timely notifications aren't useful anyway?
• Eventually, preferences.

This ends up essentially all custom so no real overlap with D16752. I think specializing this is probably the right call in the long run, though, since it will be difficult to do any sort of digest/batching if we try to reuse triggers here.