bug 1888: the expiry system tries to figure out if the new expire is largely different from the last expire.  if they are, there was probably a surge at some point and it would make a bad estimation for this expire, so it'll recompute atime delta.  but 0 is a valid last expire count (new db), so we got a div by zero error. :(
bug 1888: the expiry system tries to figure out if the new expire is
largely different from the last expire.  if they are, there was probably a
surge at some point and it would make a bad estimation for this expire,
so it'll recompute atime delta.  but 0 is a valid last expire count
(new db), so we got a div by zero error. :(

changed expiry_due to check for >100000 tokens.  if there were exactly
100k tokens, and we did the expire, it would get confused because to
leave 100k tokens in the db (safety), we would want to remove 0 tokens.

if we couldn't find a good exponent to expire from in the first pass,
we'd return without removing the expiry_running flag.  it would eventually
time out, but if we know we're not expiring anymore, we should remove it.

had a stupid bug where expiry would expire to 100000 if it wanted to keep
more than 100k tokens.  teaches you to use the correct <> symbol. ;)
(it now says keep 100k if the "to expire to" point is < 100k, which is
the correct logic...)

added a "need to do first pass" check if the last expire count is 0.
whenever that happens, last atime delta should also be 0, and that's
already checked, but ...


git-svn-id: d99324e817494df82bb0080d8e7ab74680731a10@5121 13f79535-47bb-0310-9956-ffa450edef68

apache/spamassassin,apache/spamassassin,apache/spamassassin,apache/spamassassin,apache/spamassassin