Possibly we should implement DestructibleInterface and use PhabricatorDestructionEngine instead.

That will automatically clean up edges -- including all edge types and inverse edges, should Mail ever get those. These don't matter today but seem like reasonable things that might matter in the future. It will also do stuff like clean up any mail-related tasks in the task queue today, although I don't think this is terribly important (they should automatically fail, and it's unlikely that there are any left after 90 days).

I can come up with two downsides to this approach:

First, this will also write a PhabricatorSystemDestructionLog as a side effect, which is silly/pointless when doing garbage collection, since we'd be trading one row for another one. We could add a flag to it like setDisableLogging() to turn off logging, so we aren't just moving rows around. This seems reasonable but is a little bit of work.

Second, it's much heavier than just doing DELETEs, since it does a bunch of extra queries to look for flags, notifications, etc. The GC is single-process right now, so if an install ever generates mail faster than one process can delete it the GC won't be able to keep up. I suspect this is not a real risk for a very long time, but it might become a more realistic risk for large installs if multiple GCs start using DestructionEngine or the GC process gets heavier (although we could do multi-process GC without too much trouble).

I think this is reasonable as written and avoids both these potential downsides, but if these objects get more full-fledged in the future it might be worth converting.

Perhaps relevant is that DestructionEngine also cleans up HeraldTranscript records "for free", which these probably will have soon.