Bug Report:
Compile emacs with system's gzip program set to `pigz`.
Run emacs and then `M-x eww RET`

Expected behavior:
Enter URL prompt in mini-buffer

Actual behavior:
hashing failed '/usr/share/emacs/30.0.50/lisp/gnus/gnus.el.gz'

Report:
The bug has been reproduced on emacs version 29.0.91 and HEAD which
seems to be at 30.0.50.
Later, a copy of the aforementioned file was saved somewhere else and
the program was uninstalled. Then emacs was recompiled with system's
gzip program set to GNU gzip and the initial steps were repeated and
the expected behavior was the result.
This lead to believing either that there's a bug with how zlib's
`inflate()` handles archives or emacs code was having an issue with
archives files.

The hashes for gz archives generated with different programs were as follows
> md5sum gnus-gzip.el.gz
edb3d0ffba7f19ff1d4ec3f889609e8a  gnus-gzip.el.gz
> md5sum gnus.el.gz
985deaaec6a5845ac8d6bd9648957b50  gnus.el.gz

And when uncompressing these archives, the resulting file was the same
and the hash for the files was the same (omitted for brevity).

Now after logging some code in $EMACS_REPO/src/decompress.c, it was
learned that in the pigz specific case, `inflate()` was returning
Z_BUF_ERROR(-5) which is an indicator for zstream's either `avail_in`
or `avail_out` fields are 0.

Observing the code in `$EMACS_REPO/src/decompress.c`
L154:
    } while (!stream.avail_out);
only checks stream.avail_out and not stream.avail_in which also might
have been set to 0. A special case here can be constructed where
`avail_in` is 0, and the code keeps looping even though our input
buffer is empty and thus causing a Z_BUF_ERROR. Placing a simple check
for it fixes the bug in pigz's gz archives case and does not cause any
issue with gzip archives.

A simple patch with a fix is attached below, I would also like to
thank a friend of mine cortexauth whom also helped during my debug
sessions.