Remove `blog-id-cache` cache group

[flixos90]

The function get_blog_id_from_url() is the only function that uses the old blog-id-cache group. Since the introduction of WP_Site_Query it's basically redundant in there though, since site query results are cached anyway.

Therefore I think we should remove the cache read and write actions in that function. We can then also remove the cache group completely (from clean_blog_cache() and registration as a "global group").

[spacedmonkey]

My patch removes uses of the group in core and in tests. I have removed the global group, as plugins may be using it for something.

I believe we should be getting rid of the all cache look ups that use domain / path. I believe most domain mapping solutions out there will break the cache invalidation.

[flixos90]

Per bug-scrub discussion:

Maybe we should hold off removing that cache, although it's redundant. That is because WP_Site_Query caches are invalidated on every change to any site (via last_changed), while blog-id-cache keys are only invalidated on updates to the specific site. So the blog-id-cache keys are much more "stable".

I'm not sure whether this is actually a reason to hold off, but we need to discuss and further investigate.

[heikomamerow]

@soean and me did a PR... see above

[johnjamesjacoby]

This looks great. Nice job!

[johnjamesjacoby]

Replying to flixos90:

Per bug-scrub discussion:

Maybe we should hold off removing that cache, although it's redundant. That is because WP_Site_Query caches are invalidated on every change to any site (via last_changed), while blog-id-cache keys are only invalidated on updates to the specific site. So the blog-id-cache keys are much more "stable".

I'm not sure whether this is actually a reason to hold off, but we need to discuss and further investigate.

Link to original discussion: ​https://wordpress.slack.com/archives/C03BVB47S/p1491848375654869

last_changed cache invalidation is still an issue.

Merging this PR will cause increased churn, specifically because of wpmu_update_blogs_date(), by way of _update_blog_date_on_post_publish() and _update_blog_date_on_post_delete().

[heikomamerow]

Ok, see the point. Should we close the ticket then?

Replying to johnjamesjacoby:

Replying to flixos90:

Per bug-scrub discussion:

Maybe we should hold off removing that cache, although it's redundant. That is because WP_Site_Query caches are invalidated on every change to any site (via last_changed), while blog-id-cache keys are only invalidated on updates to the specific site. So the blog-id-cache keys are much more "stable".

I'm not sure whether this is actually a reason to hold off, but we need to discuss and further investigate.

Link to original discussion: ​https://wordpress.slack.com/archives/C03BVB47S/p1491848375654869

last_changed cache invalidation is still an issue.

Merging this PR will cause increased churn, specifically because of wpmu_update_blogs_date(), by way of _update_blog_date_on_post_publish() and _update_blog_date_on_post_delete().

[johnjamesjacoby]

Replying to heikomamerow:

Ok, see the point. Should we close the ticket then?

I reached out to Barry at WordPress.com to see what his thoughts are (and if our hunch is correct or not).

Let's leave this open until we hear back?

Trac ticket: https://core.trac.wordpress.org/ticket/40362

The previous PR (#8908) was closed, so this PR proposes the same changes again for review.

## Use of AI Tools

[mukesh27]

@johnjamesjacoby Have you get any feedback from Barry? Is this in your radar for 7.0?

Q: Why it moved to type task is there any specific reason behind that?

[johnjamesjacoby]

@mukesh27 have not heard back.

I would like to revisit the last_changed cache churn now that items are salted via r60697.

I switched it to a Task because it isn’t a bug/defect, and it isn’t necessarily enhancing any existing functionality, but is work that has merit to complete. I don’t feel strongly about ticket organization though so feel free to adjust.

OK to revisit this in 7.1 IMO.