Make cache TTL for revision-keyed entries equal to quantization window instead of 2x quantization window

[tstirrat15]

Or at least revisit where Otter starts counting. Currently we're using ExpiryAccessing, which means the timer starts from the last time the entry was accessed; 2x the quantization window means that the max life of an entry is 4x the quantization window, assuming that the access is smeared and the entry was created at the beginning of the quantization window and read at the end of the smeared quantization window.

We can probably tighten that up, either by changing the policy to be based on creation/write rather than access, or by making it so that the TTL is just the quantization window. This should reduce overall SpiceDB memory usage somewhat.

[breken-ai]

Fixed - PR: #3302

Someone reported that revision-keyed cache TTLs extended on every read; verified against the otter cache setup and switched to ExpiryWriting so entry lifetime is bounded by the configured TTL regardless of read traffic. ttlExtensionFactor deliberately left at 2x (staleness/follower-delay margin) - cutting to 1x is a one-line follow-up noted in the PR. New synctest test fails on main, passes with the fix; pkg/cache suite green with -race.

Built by breken, your AI support engineer - breken.ai finds the bug, proves the fix with unmatched RCA, answers customers in your voice, and keeps your code and support docs clean - this one's on us.

[jzelinskie]

I believe our previous behavior with Ristretto setting a TTL of 2*quantization window was also incorrect. Because the max staleness flag does not have a maximum value, by setting --datastore-revision-quantization-max-staleness-percent to any value greater than 1, it might smear over >2 quantization windows (e.g. 3 aka 300% blends across 4 windows).

If this is the case, the desirable TTL for should be based on the max staleness and the quantization window:

VALIDITY_WINDOW = (ceiling(max-staleness-percent)+1) * quantization window
TTL = VALIDITY_WINDOW - time.Since(REVISION)

Orthogonal to this conversation, it might make sense to remove configuration of the quantization window entirely, and instead only expose the max staleness. This would remove the footgun for users configuring large quantization windows with out having any blending between them.