Allow developers to select which image format to use for images in the content

[eugene-manuilov]

Summary

Fixes #187

Relevant technical choices

Checklist

• PR has either [Focus] or Infrastructure label.
• PR has a [Type] label.
• PR has a milestone or the no milestone label.

[mitogh]

Minor comment about the code.

Would be great to introduce some tests to test cases like:

• Default behavior
• Reverse behavior
• Empty value
• Unsupported mime types

[felixarntz]

@eugene-manuilov Looks great, just one comment.

[adamsilverstein]

Overall looks good although I still prefer to have the filter operate in the opposite order. Also, it would be good to add some tests verifying that the filter works as expected.

[felixarntz]

@adamsilverstein

Overall looks good although I still prefer to have the filter operate in the opposite order.

The benefit of how it currently behaves is that the order of how items have to be sorted in the filter itself is arguably more aligned with the other filter, with the "foundational" format coming first (typically JPEG for our purposes currently). The reason we then iterate through the array backwards here is because the "priority order" of the formats would be actually the opposite, which especially makes sense when thinking about it in the context of future picture element support. Basically, the most advanced modern format should come first, but it's also the most likely format to not be supported by the browser. So there have to be fallbacks, all the way back to the "foundational" format which is expected to work everywhere.

Also, it would be good to add some tests verifying that the filter works as expected.

+1 to that, @eugene-manuilov could you add a few tests for the filter usage?

[adamsilverstein]

which especially makes sense when thinking about it in the context of future picture element support.