Cache simple repository pages

[dimbleby]

At #5868, I suggested that some of the caching that was being reworked could be removed altogether, because cachecontrol was already taking care of it just fine.

But now I find myself using an Azure artifacts repository, and it is returning headers that insist that the client does not do any caching:

cache-control: no-cache
pragma: no-cache           
x-cache: CONFIG_NOCACHE 

(pypi, by contrast, sets max-age to 10 minutes here).

So I was wrong! And now I am seeing a big performance hit in some projects where the solve involves overrides and backtracking: and therefore hitting the legacy simple API repeatedly.

However, we don't need all the mechanism of cachy and its like for this, a well-placed @lru_cache() seems more than sufficient.

This makes me wonder whether it wouldn't be better to do similar for pypi anyway, and rip out cachecontrol altogether. But let's keep it simple for now: this is an easy fix to a performance regression.

[dimbleby]

• flake8-bugbear doesn't like lru_cache on a method because it thinks we might be leaking memory
• mypy doesn't like the self.method = lru_cache()(self._method) trick in a subclass where the parent already defines self.method

keeping everything happy is kind of annoying: I've refactored so that .get_page() rather than ._get_page() is the preferred, caching, method.

[neersighted]

This is the same way we handled get_repository_config_for_url caching, so I am more than fine with the approach. Ideally we'll move to functools.cache instead of lru_cache once we eventually, in the distant future drop 3.8 support; however I think pyupgrade can likely be taught to make that change instead of leaving a comment.

[radoering]

I removed the changelog label because this fixes a performance regression of an unreleased version (if I understand correctly).

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.