Registry expiration as opposed to removing it too soon

Marking needs work, patch failed to apply

Rebased MR and added 2 extra commits:

• 30cb67ca - Added 1 hour; 3,6,9,12 hours; 1 day; 1 weeks.
• 12a436fb - Phpcs fixes.

I think this is something that the module should be doing and the approach looks sensible to me - thank you.

I looks like an unintended change was introduced that broke the tests - I think we will also need more test coverage that the expiration is working.

Have fixed the existing test and taken a closer look.

I think we need to be mindful here for pages using the internal page cache module.

The behaviour for page_cache is permanent by default:

    // The response passes all of the above checks, so cache it. Page cache
    // entries default to Cache::PERMANENT since they will be expired via cache
    // tags locally. Because of this, page cache ignores max age.

While some setups will have the internal page cache disabled and rely only on an external page cache, not all will.

If page cache is enabled, it looks like the url registry item is removed after expiration, but as the page cache entry is permanent it will remain and continue to be returned by Drupal this never gets added back to the registry because of:

    // When page_cache is enabled, skip HITs to prevent running code twice.
    if ($cached = $response->headers->get('X-Drupal-Cache')) {
      if ($cached === 'HIT') {
        return FALSE;
      }
    }

I haven't thought too much on this - perhaps we can just return TRUE here? We don't introduce anything negative for sites without page cache, as the response won't have that header.

Will need a rebase after #2912139: Logged-in requests remove items from traffic registry comitted.

While that related issue is committed I am still keen on this idea as a solution.