Instead of tracking individual keys, only track the trailing revision

Seeking over a list becomes very inefficient as the list grows (duh),
so we instead just track the last cleaned up revision, which achieves
the same. I ran into this in the imap resource when syncing large
amounts of new data, with the removed list growing into the thousands
because there was always a sync going on (and thus a write transaction),
when items have been dequeued by the processor.