feat: Start conversion of StaticContentServer from middleware into view

[timmc-edx]

See #34702

This necessarily involves switching from calling StaticContent.is_versioned_asset_path to determine whether to handle the request to having a hardcoded urlpattern. I've made the choice to hardcode the other two patterns similarly rather than using imported constants. The mapping of URL patterns to database records should be explicit (even though we don't expect those constants to change out from under us.)

I've renamed the middleware rather than choosing a new name for the implementation because there are other references in tests and other code. This was the option with the smaller diff.

A note on HTTP methods: The middleware currently completely ignores the request's HTTP method, so I wanted to confirm that only GETs were being used in practice. This query reveals that 99.8% of requests that this middleware handles are GET, with just a smattering of PROPFIND and OPTIONS and a tiny number of HEAD and POST:

from Transaction select count(*) facet request.method
where name = 'WebTransaction/Function/openedx.core.djangoapps.contentserver.middleware:StaticContentServer'
since 4 weeks ago

Testing instructions

I've tested this in devstack using http://localhost:18000/asset-v1%253AedX+DemoX+Demo_Course+type@asset+block@images_images_course_image.jpg with the flag on and off. There's some minor difference in response headers around accept-language and vary, but they both have Vary: cookie so I don't think that will affect much.

I also tested 404 responses, and both 200 and 404 from the CMS as well.

When testing this in deployed environments we can watch for changes in response status, new or different errors, and unexpected telemetry data (from the "shouldn't happen" branches).

Deadline

None