destroying a readStream for a compressed entry may cause a memory leak

[thejoshwolfe]

I'm not actually sure this is a problem, but I think it is. The zlib module appears to offer no way of aborting an inflate stream in progress. Currently, yauzl just unpipes and abandons it hoping that the GC will do something helpful. But since there are C resources supporting the JavaScript API, this is probably causing a memory leak.

[thejoshwolfe]

I did some science on this, and I concluded that this is not an issue.

The default window size for zlib inflate is 32KB, and so the expected memory usage after triggering the possible memory leaky 1 million times is 32GB of ram.

I ran a test which repeatedly triggered the possible memory leak, and although the memory usage was much higher than I was expecting (1251M VIRT, ~160M RES, ~12K SHR), it stabilized quickly. After 1 million iterations of triggering the possible memory usage, the highest number in the memory usage was only ~1G, not 32G. I'm considering this issue resolved.