Incorrect read bytes when seeking in non-deflated resources with Minizip

[mickael-menu]

Unfortunately, a recent fix I made to improve PDF performances introduced a regression in seemingly random cases, where the content of a decrypted file is shifted.

This issue was caught by a unit test, but I couldn't find a fix, and didn't notice any actual issue during live testing. Since then with further testing in production, we noticed the bug happening randomly. Therefore, I will revert the fix in an upcoming PR.

For more in-depth explanation, it looks like the version of Minizip we're using has an issue with unzseek64(). When seeking from the start of the resource, it will count from the ZIP entry header, instead of the actual content. Any subsequent read() might therefore read part of the ZIP header, and the end of the actual content is not reachable (shifted). I "fixed" this by attempting to read a few bytes before seeking a "fresh" entry, but this caused some random crashes.

Possible solutions:

• Upgrading Minizip. Not easy, because we're already at the last version of the Swift wrapper, but we might attempt using directly the official C++ lib.
• Switching to another lib. There are not many available for iOS. A big contender (that we're already using with r2-lcp-swift) is ZIPFoundation, but I didn't find any equivalent to the unzseek() function after a quick search.

[mickael-menu]

More insights on how to fix this:

• Adding a way to return a custom SeekableInputStream from a Resource, to return a special implementation in the case of a ZIP stored resource: It would seek from the start only if the next requested range is located before the current offset.
• We could implement unzseek in ZIPFoundation, theoretically we just need the offset of the entry in the archive and use regular file seeking, without using the ZIP APIs since it is not deflated.
• Since a PDF is actually loaded fully from the start (albeit with byte ranges), we could disable byte ranges support in the HTTP server for stored entries, to force the consumer to download it entirely, thus avoiding the chunking.

[mickael-menu]

This PR fixes the slow PDF performances by caching the ZIP input stream. However the original problem remains and we should migrate to a better ZIP library at some point.