[Zimit] App loads malformed PDFs when the PDF is loaded via an HTML redirect

[Jaifroid]

Due to the blocking of PDF loading in sandboxed iframes in Chromium (see kiwix/libkiwix#916 and kiwix/libkiwix#948), I had originally introduced a workaround consisting of parsing anchors. As a side-effect of economizing code with a similar routine used in jQuery mode, this used a custom download routine, but that download routine is incapable of dealing with the fact that, anomalously, some Zimit archives store PDFs indirectly: when you attempt to load a PDF file, instead you get an HTML redirect to the PDF file. The custom download routine then serves the HTML as a blob with PDF headers... Which of course doesn't work.

The fix is twofold:

• In SW mode, we should use the simpler code I discovered for Kiwix JS, which doesn't parse every link but merely intercepts a click on the iframe, inspects it, and sends the content to a new window. The browser then handles the redirect transparently.
• In jQuery mode (Zimit ZIMs like www.ready.gov can be opened even in Internet Explorer, as the underlying Web site is designed to be readable in all browsers), we will have to handle this anomalous situation, because we are forced to download PDFs "manually". NB This part is not related to sandbox blocking, it is the download method itself that is incapable of dealing with PDFs served as HTML redirects (not something I could have foreseen...).

This issue mostly affects Zimit archives, though it could conceivably affect other archives as well, if a PDF is legitimately stored via a redirect that is not a standard dirEntry redirect.

[Jaifroid]

This should be fixed with 794b1e6, efbf267 and 7e7cf4b. I'm keeping open while testing.