Convert more zlib warnings to exceptions

[bor0]

This PR further extends the functionality of a previous PR #4985.

Ran into this while working on a particular WordPress functionality - our servers reported tons of warnings. Currently, the only way to avoid warnings is to call @gzinflate, but silencing errors is discouraged so we also have to phpcs:ignore it. If gzinflate threw an exception instead, it would be much easier for developers to handle this.

Applied same reasoning to all the zlib functions.

I also found out that the json extension also does not use any notices:

bor0:~/dev/php-src/ext/json$ grep -R php_error_docref *
bor0:~/dev/php-src/ext/json$

⚠️This is a breaking change and may cause code flow interruptions unless handled with exceptions⚠️

[bor0]

cc @Girgias @nikic for visibility, who reviewed the previous PR.

[Girgias]

The implicit policy is that we don't use exceptions/errors for states that cannot be programmatically checked in advance.

As such, I don't think we can do this. The BC break especially feels like this requires an RFC.

[bor0]

@Girgias, thanks for your comment.

The implicit policy is that we don't use exceptions/errors for states that cannot be programmatically checked in advance.

So if we strictly follow this policy (which isn't necessarily followed for other extensions across), does that mean silencing function calls is the preferred way to do it properly?

As such, I don't think we can do this. The BC break especially feels like this requires an RFC.

I am okay to file an RFC for this, maybe after I get more comments about what people think of this PR in general.

Just a note, #4985 created similar backwards incompatibility - curious if it had (or if it was necessary to have) an RFC?

[Girgias]

@Girgias, thanks for your comment.

Just a note, #4985 created similar backwards incompatibility - curious if it had (or if it was necessary to have) an RFC?

The errors introduced in that PR are things that you can check in advance are always valid, such as the compression argument being in a valid range or that one uses one of the ZLIB constants, i.e. programming errors.

The warnings you are trying to promote are warnings that are emitted by the C library, and cannot be checked in advance as they depend on the archive.