Stream proxied S3 and Azure artifacts

[dralley]

Bypass django-storages eager file buffering when the content app proxies S3 or Azure artifacts. Preserve the generic storage fallback and HTTP range behavior.

closes #7806

Assisted By: Codex (GPT-5) Terra 5.6

📜 Checklist

• Commits are cleanly separated with meaningful messages (simple features and bug fixes should be squashed to one commit)
• A changelog entry or entries has been added for any significant changes
• Follows the Pulp policy on AI Usage
• (For new features) - User documentation and test coverage has been added

See: Pull Request Walkthrough

[dralley]

Ideally none of these wrappers are necessary, and django-storages would allow us to do something like this natively: jschneier/django-storages#1568

But for now, we cannot, and the buffering implementation is genuinely unsuitable for sufficiently large files (context: a user has reported that they are storing files ranging up to 60 or even 300 gigabytes)

[dralley]

Obviously this is relatively invasive, so we need to be very careful with testing.

[dralley]

Alternatively, we could temporarily fork django-storages and add better APIs directly to the implementation. It is not in a great place maintenance-wise anyway currently.

[dralley]

Here is what the upstream PR looks like jschneier/django-storages#1569

[dralley]

@mdellweg I'm marking this draft because it probably needs more extensive testing, however, I would still like feedback on the direction and approach. e.g. if you want to try the "vendor/fork django-storages" approach.

Both the issue itself and the upstream status of the library is a real issue we're going to need to deal with one way or the other.

[mdellweg]

First, I don't know what the best approach is. Each approach has pro's and con's.
There might be a lightweight approach to vendoring, like we do with drf-spectacular. We monkeypatch the classes from there heavily including private interfaces. It comes with its own set of pain.