Fix #93: handle very long expirations without blocking others

[gcloudream]

Problem

Using extremely large TTLs (e.g., Long.MAX_VALUE or values that saturate to it) can break expiration scheduling. The code computes expectedExpiration = now + duration in nanoseconds. With a huge duration this overflows to a negative value, making that entry look like the earliest expiration. The scheduler then computes expectedExpiration - now, which underflows to a massive positive delay (~292 years). Because ExpiringMap schedules one entry at a time, short TTL entries stop expiring.

Fix

• Use saturating addition when computing expectedExpiration to avoid overflow.
• Treat Long.MAX_VALUE as "no expiration" and skip scheduling such entries.
• Clamp delay when already due to avoid negative/overflow delays.

Tests

• Added Issue93 regression test to ensure a very long TTL does not block short TTL expirations.