Add utility method for explicitly setting cache tags to cache tag class

[agjohnson]

This was the first attempt to fix #12494, then was broken up into multiple stages of work. This is a very minor method addition to the cache tag class, used when project/version are not set on the view instance at the class level. This was an issue in multiple views.

• Finally adds support for robots.txt cache tagging on a per-version basis
• Adds missing tests for cache tagging on robots.txt

[read-the-docs-community]

Documentation build overview

📚 dev | 🛠️ Build #29792796 | 📁 Comparing f4b316d against latest (2742aa0)

🔍 Preview build

No files changed.

[read-the-docs-community]

Documentation build overview

📚 docs | 🛠️ Build #29792797 | 📁 Comparing f4b316d against latest (2742aa0)

🔍 Preview build

Show files changed (2 files in total): 📝 2 modified | ➕ 0 added | ➖ 0 deleted

File	Status
build-customization.html	📝 modified
reference/git-integration.html	📝 modified

[ericholscher]

I think this likely also might have downstream permissions issues on .com. We should double check that these aren't being cached on .com.

[agjohnson]

We should double check that these aren't being cached on .com.

This only affects cache tagging for purging, so shouldn't have an effect on caching.

[humitos]

I think this is going in a good direction. I haven't done a deep review yet but I understand that the idea is to change the login from "leave the mixin to handle cache tags (after implementing 2 methods)" to "set the tags manually by the class itself", right?

I'm not opposed to that, I think it's more explicit and easier to digest as well.

I don't have all the implications of this change in mind. Do we need to make changes in .com as well? I think @stsewd is a good candidate to chime in here since I think he has implemented this code originally.