fix: Detect corrupted files, exit on exception (DEV-4457)

[siers]

This corruption warning is non-fatal, so we have to check if the error code is set to a specific JWRN after jpeg_read_scanlines. Test added that an exception is created in img.read.

---

References:

https://github.com/mozilla/mozjpeg/blob/6c9f0897afa1c2738d7222a0a9ab49e8b536a267/jerror.h#L195

JMESSAGE(JWRN_HUFF_BAD_CODE, "Corrupt JPEG data: bad Huffman code")

https://github.com/mozilla/mozjpeg/blob/6c9f0897afa1c2738d7222a0a9ab49e8b536a267/jerror.h#L280-L283

/* Nonfatal errors (we can keep going, but the data is probably corrupt) */
#define WARNMS(cinfo,code)  \
  ((cinfo)->err->msg_code = (code), \
   (*(cinfo)->err->emit_message) ((j_common_ptr) (cinfo), -1))

https://github.com/mozilla/mozjpeg/blob/6c9f0897afa1c2738d7222a0a9ab49e8b536a267/jdphuff.c#L551-L552

        if (s) {
          if (s != 1)           /* size of new coef should always be 1 */
            WARNMS(cinfo, JWRN_HUFF_BAD_CODE);
          CHECK_BIT_BUFFER(br_state, 1, goto undoit);

https://github.com/mozilla/mozjpeg/blob/6c9f0897afa1c2738d7222a0a9ab49e8b536a267/jdhuff.c#L463-L466

  if (l > 16) {
    WARNMS(state->cinfo, JWRN_HUFF_BAD_CODE);
    return 0;                   /* fake a zero as the safest result */
  }

[linear]

DEV-4457 Sipi creates corrupted file from a corrupted file (Bad Huffman code)

[jnussbaum]

Hmmm, does that mean that in the past, all SipiImageError resulted in return code 0, but now, they will all result in return code 1?

That would not be the expected behaviour. Because often, an image is only slightly corrupted, but perfectly readable by most viewers. For example, the ca. 66'000 images of LHTT produced ca. 14'000 error logs. But most of them are negligible, because there is no real defect in the image. We'd like that SIPI only aborts with non-0 in these very specific cases:

• Corrupt JPEG data: premature end of data segment (https://linear.app/dasch/issue/DEV-4480)
• Corrupt JPEG data: bad Huffman code (https://linear.app/dasch/issue/DEV-4457)

[siers]

Very odd, but it was also my intention to check whether this new behavior breaks the build. Unfortunately the main build is broken. 🤦

Anyhow, I'll restrict it to the behavior you've described.