Seek on archive streams, avoid requesting all bytes

[lmmx]

• Branching from #9, upon realising that downloading all package bytes would be slow for large packages

To speed up the async procedure over many archives, it'll be better to seek on zip/tar.bz2 streams rather than just download all bytes and then process them synchronously

• Zip files end with a "central directory"
• Tar files have one continuous stream whose "header" blocks describe the file and how many bytes it consists of, meaning you can seek the range after it to find the next one

TODO: make a plain tar (no compression) and see what this looks like (apparently it's ASCII)

[lmmx]

The central directory at the end of a zip is marked by the signature (or "magic number") b"PK\x01\x02". This can be retrieved by requesting the final 500 byte range (or 300 bytes to take a chance)

• To begin with, I could just set up the check on the 300 bytes and see if I need to actually bother writing the iterator logic or if it'll always be found in the 300 bytes...

After this signature (just split on this signature and then parse after it) there are various entries in the central directory struct, of which only the filename length is of interest...?

• zipfile._CD_FILENAME_LENGTH = 12, i.e. the 12'th entry following the signature

This is better delegated to the RangeStreams library

[lmmx]

Refer to notes on the structure of zip files

[lmmx]

✅