Small TTL values can get lost by client/server clock-drift

The .NET client library always sends TTL values as absolute "since EPOCH" time-stamps. This causes problems if you have a small TTL and there's clock-drift between client server.

Example
client clock is 14:00
server clock is 13:58 (not uncommon to have minutes of drift)
client adds a document with a 10 second TTL. This is actually sent as 14:00:10

The client will find the document still lives until the server clock reaches 14:00:10, some 2 minutes later than when the document was added.

CB server overloads the time-stamp field in the memcached wire protocol. The 4-byte field used for TTL info is interpreted as an absolute UTC, EPOCH timestamp for values over 2592000 seconds (30 days since EPOCH). Values under that are just treated as seconds to live.

For the Store method which accepts a TimeSpan TTL we should be sending TTLs under 30 days as seconds, not EPOCH. This protects the client against the clock drift issues.

The DateTime Store method must be left alone and always send EPOCH TTL.