Passive invalidation via last_changed should use timestamps

[westi]

For #23173 we are switching lots of things over to passive invalidation via cache incrementors and last_changed.

This includes switching the oldest thing we had using this method of invalidation over to using wp_cache_incr.

This ticket is a petition to use time() still as the initial value so as to avoid race conditions with cache evictions and cache incrementors.

Currently with a 1 based last_changed key the following is possible with a persistent object cache backend like memcache:

• last_changed is set to 1
• list of pages is cached with 2 pages being the result of a get_pages call
• last_changed is evicted from the memcache server
• Another page is added
• A call to get_pages happens, sets last_changed to 1 and returns the old data

Confusion the reigns for a bit until other things are evicted or another change is made.

If we start with last_changed = time() then we have no danger of using stale cache entries.

Switch to time() based last_changed

This patch should fix all these issue, it breaks all the tests that assume we start from 1 and increment up though ;)

How about microtime()?

A reminder that a bunch of unit tests will need to update. I can get those.

+1000, but anything random enough should be good.

Replying to ryan:

How about microtime()?

That would work too, anything that doesn't always start somewhere deterministic is what matters :)

In 23401:

Use microtime() instead of incrementors for last_changed to to avoid race conditions with cache evictions.

Props westi
fixes #23448

​[UT1206]

​[UT1208]

​[UT1209]