Unauthenticated session expiry

[mmd-osm]

Follow up for openstreetmap/operations#1107

The goal of this PR is to set the expire_after value for unauthenticated users to a fairly low value (read: a few hours). This way, memcached entries are no longer created with a TTL of 0 (unlimited).

Previously, logged on user sessions were evicted first, because their TTL is set to 30 days in session_persistence.rb / session_methods.rb. As a result, a number of users reported that they had to repeatedly sign in to osm.org, since their session was gone.

The chosen approach is based on what Gitlab is doing in https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/middleware/unauthenticated_session_expiry.rb, with the difference that I replaced redis by memcached, and warden by a simple logged on user check.

osm_session cookies inherit the same low expire_after value now, rather than being session cookies. I don’t think this should be causing issues. This needs to be doubled checked as well. Cookies for unauthenticated users are primarily used for csrf protection, and are updated with every backend roundtrip. They are not relevant for API endpoints.

It still needs some tests. However, I'm not sure what the best way would be.

---

Prometheus stats: https://prometheus.openstreetmap.org/d/l4zgNUdMz/memcached?orgId=1&refresh=1m&var-instance=spike-06&var-instance=spike-07&var-instance=spike-08&from=now-30d&to=now

[tomhughes]

Not sure why you closed this? I actually spent some time yesterday digging into it...

I am interested in knowing if you've found any sources backing up the theory that entries with no expiry can somehow swamp out ones with an expiry as I'm not really clear on how that would happen?

[mmd-osm]

I can't validate the assumption in production and don't know what test cases to add. Or in other words, I was stuck with the current state and decided to close it, as there's no way to make any progress on it.

Assuming a slab is full and new entries need to be added. There are two possible options: entries that expire sooner (rather than never) get evicted first, or some random entry will be evicted. Both options are bad, since they might remove valid user sessions.

To me, this question is not super important. I would rather let the LRU crawler clean up short lived anonymous sessions as soon as possible, and never get to a state where eviction is unavoidable. Ideally, this change would keep the items in the cache at a very low number all the time, and never get to a point of 80%+ memory usage.