Allow for garbage after comment data

[davide-romanini]

Many zip in the wild could have some garbage after comment data, and normal zip tools silently ignore the garbage and preserve the good data.
This PR just removes the check that, in case of garbage, removes all the comment, preserving more zip data.

[rylev]

Thanks for this. Could you add a test for this?

[Plecra]

I'm not sure this is permitted by the ZIP spec. @davide-romanini Could you give us example(s!) of ZIP files like this?

[davide-romanini]

@rylev I've added a test with a small sample of the issue.
@Plecra specs may or may be not allow for this. But reality is often different, especially for a format so old.
In my case I found that python zipfile generates garbage when opening a zip in mode a and setting a comment with a shorter length than the initial one:

>>> from zipfile import ZipFile
>>> with ZipFile('comment_garbage.zip', 'a') as z:
...     z.comment = b'long comment bla bla bla'
...
>>> with ZipFile('comment_garbage.zip', 'a') as z:
...     z.comment = b'short.'
...
>>>

This doesn't cause any problem for other zip reading libraries, so I think it should be handled even if not officially supported by the spec.

[rylev]

@Plecra This seems reasonable to me. Thoughts?

[Plecra]

@davide-romanini Thanks for such a simple example 😀 This has made it very clear.

7zip lists it as a warning, but the file doesn't seem to break any of the common ZIP readers. So the question is how far we should go in supporting these files: The comment length is the only thing that bounds the time it takes to open the ZIP files (which is important for negative ID), so will we still only search within the first ~65536 bytes? I'd like to check InfoZIP's implementation for how they handle this, in case there's another oddity.

[Plecra]

No need for this to wait any longer. Thanks for your work @davide-romanini