Fix the behavior of TTL to allow more than 30 days

This is a backwards compatible change for those who use timestamps as
TTL but now allows for TTLs greater than 30 days. The only case this
will not be backwards compatible is when someone depends on the instant
expiration behavior of setting a TTL between 2592000 and the current time.

The API of interpreting TTL as a UNIX timestamp depending on value is
non-intuitive and prone to create bugs. Instead, only interpret this
value as a UNIX timestamp when it's a more larger number that can be
reasonably assumed as a timestamp. I chose a billion seconds. This
translates to a 9/9/2001. This is a number that is much less likely
to cause issues.

I had considered making the minimum value the server start time, or
a time around it. The issue there is that we cannot assume callers have
their clocks set correctly. There would be an edge case where a caller's
clock is behind and the TTL ends up being 30 years. The choice of a
billion seconds gives a padding of 13 years of caller clock accuracy.

Also changed a check that seemed unintuitive -- it was adding 1 to
REALTIME_MAXDELTA and will set it to one again anyway.
I'll fix the comment, but:

"IMO, 30 days is long enough for a cache"

It's not for us, hence the patch.

The issue to overcome is a poor API that switches between time and UNIX timestamp at an arbitrary threshold rather than providing a flag or some explicit method to make that distinction. A billion is just as arbitrary as 2592000, but it allows a reasonably good distinction for "modern UNIX time stamp" and keeps some backwards compatibility with a questionable API decision made a long time ago.