Strategy: Temporarily remove response caching

[samford]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally?
• Have you successfully run brew man locally and committed any changes?

---

This is a follow-up to #9529. I meant to address the code where header and body content for responses were being cached in @headers and @page_content hashes (using the URL as the key) but forgot along the way.

The issue as I see it is that the simple approach here caches all header or body content from responses, so memory usage continually grows over long livecheck runs (e.g., --tap homebrew/core).

Instead, we should only cache the header/body data for URLs that we know will be fetched more than once in a given run. The naive approach here has been fine for the Xorg strategy, only because the number of pages being cached is very small. A run across homebrew/core could potentially cache 2000+ pages, which is significant.

Being able to determine which URLs will be fetched more than once requires structural changes within livecheck strategies, so this will take a bit of work to implement. I've been implementing this off and on (as time permits) and I'll introduce a more sophisticated method of livecheck-wide caching in a later PR. The required changes to strategies also coincide with some refactoring that I already had planned to be able to improve the testability of livecheck code, so that work will be used regardless.

In the interim time, it's best to remove this naive caching behavior until I've finished working on an approach that provides the benefits we want (reducing duplicate fetches) while minimizing detriments (increased memory usage).

Labeling this as critical, so we can get this in ASAP.

[BrewTestBot]

Review period ended.