feat: let the content app return 304 Not Modified for unchanged files

[carlosthe19916]

Summary

• After content guards allow the request, the content app can answer If-Modified-Since with 304 Not Modified and no body, so an edge cache can keep its copy instead of downloading the file again.
• Last-Modified is when that unit joined the served repository version (RepositoryContent.pulp_created). Disk mtime moves on copy/restore, and the version’s created time would make every cached file look stale on each publish.
• This only applies when Pulp sends the bytes (filesystem or ArtifactResponse). Object-storage 302s get neither Last-Modified nor Cache-Control: public, because a signed URL must not be stored or reused as if it were the file.

Fixes #7929.

Guards still run first. A matching If-Modified-Since is 304; otherwise the response is 200 with Last-Modified and the body. If there is no membership row (publish-generated metadata, remote-only distribution), Pulp omits Last-Modified and never returns 304.

Artifact 200s and 304s include Cache-Control: public, max-age=0, must-revalidate so the edge revalidates on every use. Plugins can still override headers with content_headers_for. This change does not add ETag.

_serve_ca is the single place that looks up the timestamp and may 304 (published files, pass-through, repository versions, plugin content_handler(), grace-period fallback, pull-through). Grace-period fallback uses the old publication’s version so the timestamp is not the current one. On-demand streams 304 before opening the remote. A stream that has already started writing is never turned into a 304.

aiohttp’s FileResponse would overwrite Last-Modified with disk mtime. PulpFileResponse stops that, does not send a disk-time ETag, and does not clear If-Range.

When Redis is on, the handler returns a cacheable 200 and the cache layer owns the 304: it stores last_modified, 304s a hit without rebuilding the response, and never writes a 304 into Redis.

Not in this PR: 304 on S3/Azure/GCS redirects, ETag / If-None-Match, or a fallback timestamp for metadata with no membership row.

Test plan

• Handler: 200 vs 304; no handler 304 when Redis is on; 302s stay unmodified; 304 beats an unsatisfiable Range; on-demand 304 before the remote fetch; timestamp from repository membership
• PulpFileResponse does not 304 on file mtime and does not clear If-Range
• Redis stores last_modified, 304s a hit without rebuilding, and never caches a 304

[gerrod3]

I really don't like what the AI wrote. Here's how I would have done it: 5164e37

The AI is somehow doing too much and too little at the same time. Lots of refactoring and not even implementing full functionality for the cloud backends. And man, AI really does love adding tests... After I spent so much effort to reduce the test suite time too.

Can you implement something similar to what I wrote? I haven't fully tested it and the utility method isn't all there, but it's a better approach, imo. Also, can you do some tests with the queries I wrote for finding the Last-Modified time vs the ones you used? I recall _content_relationships being a big bottleneck on services, so not sure it's a good idea to call it for every request again, but maybe the content=ca.content filter speeds it up.