Add `send-scaled-img:` handler for Workhorse

What does this MR do?

We are currently exploring solutions to auto-scaling images on GitLab. While we haven't made a final decision yet which exact approach we will take, one promising avenue is to do this on-the-fly, whenever the frontend/client requests a particular width for an image to be returned.

Most of the heavy lifting is done in workhorse, but we need a Rails handler to authenticate the request, do a couple sanity checks (such as is a correct width provided) and render out the respective instructions for workhorse to then act on this request.

The workhorse changes are still in progress, but it is safe to ship the Rails changes already, as they are feature-flagged and gated to specific users for whom we will enable this functionality. This would make it a lot easier as well for us to experiment with this feature on an ongoing basis. If we decide to use a different approach, it is easy enough to drop it again.

For this to work, workhorse must implement an injecter for send-scaled-img. There is a proposal for how to do that here: gitlab-workhorse!546 (merged)

This MR should not be blocked on the particular WH implementation, however, as long as it is behind a user-gated feature flag.

Implementation

We use a similar approach to the send_url feature. Upon receiving a request for an upload entity, we first check whether it is an image file, and whether a width was requested. If so, we:

• construct Gitlab-Workhorse-Send-Data header with the new send-scaled-img command, including
  • the location of the image file (can be local or remote)
  • the requested width
• render 200 OK to workhorse
• workhorse recognizes the header, unrolls the parameters embedded in it, reads the image file, resizes it and renders it out to the client

Feature flag

• dynamic_image_resizing
• Issue: #233704 (closed)

Screenshots

Before

After

Does this MR meet the acceptance criteria?

Conformity

• [-] Changelog entry Highly experimental and behind feature flag, so we will not announce this yet.
• [-] Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• [-] Database guides
• [-] Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

Security team is already involved in this epic via https://gitlab.com/gitlab-com/gl-security/engineering/-/issues/1043

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team