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.
“Negative exptimes can underflow and end up immortal. Let's expire the value immediately instead” --it seems that you are not doing what the comment said:)
IMO, 30 days is long enough for a cache.