Fix auxlib.logz.stringify excess memory allocation

[mbargull]

Description

This addresses the excess resource usage observed in gh-13541.

Essentially, the whole repodata.json is parsed via requests.Response.json and then dumped into a formatted string -- with both parts allocating multiple GB in RAM for large channels like conda-forge.
All this happens in a context only for (intended) debug logging output which is meant to constrain the log message length (and in turn memory usage); the proposed changes just apply the intended size constraints.

(It only handles the severe run time impact but doesn't fix the underlying cause for gh-13541.)

Checklist - did you ...

• Add a file to the news directory (using the template) for the next release's release notes?
• Add / update necessary tests?
• [ ] Add / update outdated documentation?

[codspeed-hq]

CodSpeed Performance Report

Merging #13628 will create unknown performance changes

_{Comparing mbargull:fix-auxlib-stringify-contenxt_max_len (85dc7b4) with main (1f63bef)}

Summary

⚠️ No benchmarks were detected in both the base of the PR and the PR.

[dholth]

This is concerning. It would be better to never instantiate response.text for example the jlap / repodata.json.zst code tries to stream the response directly to disk. Thanks for working on this!

[mbargull]

It would be better to never instantiate response.text for example the jlap / repodata.json.zst code tries to stream the response directly to disk.

Yes, ideally we'd always stream this.
As is, the code calling stringify also uses requests.Response.text, so this should not pose much impact.
I.e., there are multiple places for us to replace whenever we get to using streaming for all repodata.json handling.

[jezdez]

This reminds me that we need to find a way to track memory usage in the performance tracking somehow.