Skip server-side resizing for image formats that can be read but not written

The Image plugin resizes an image attachment on the server (e.g. for ?width= URLs) only when its media type is supported by the image processor. DefaultImageProcessor#isMimeTypeSupported (also used by the default thumbnailator processor) only checks that Java ImageIO has a reader for it (ImageIO.getReaderMIMETypes()), but the resized image is then written back in the same format.

When an ImageIO plugin that can only read a format is on the classpath (e.g. TwelveMonkeys imageio-webp, which is read-only, any future JPEG XL reader, or a plugin an admin adds to WEB-INF/lib), each resize request for such an image:

• decodes the full image,
• fails to write the resized image because there is no writer for the format,
• logs a warning and serves the original image,
• doesn't cache anything, so the next request does the same work again.

The result is the same as when there is no reader at all (the original image is served), but with the cost of decoding the image and a warning in the logs on every request.

Proposal

Consider a media type as supported only when ImageIO has both a reader and a writer for it (e.g. ImageIO.getImageWritersByMIMEType(mimeType).hasNext()), so that such images are served directly, without decoding them.

With the default distribution this doesn't change anything (all the bundled readers have a matching writer), but it makes it safe to add read-only image formats later, e.g. to support WebP, AVIF or JPEG XL.