Rework how we declare ZSTD min/max constants.

[michael-grunder]

These values are actually runtime in nature and can be retrieved with ZSTD_minCLevel() and ZSTD_maxCLevel() respectively.

Fixes #2487

[vlakoff]

Refs another issue that this PR fixes: 2a6dee5#r141929441 (a comment I posted in a commit, but such comments usually lack visibility).

[remicollet]

For now, in config.m4 we have

      if $PKG_CONFIG libzstd --atleast-version 1.3.0; then

from ZSTD changelog

v1.3.6
api : minimum negative compression level is defined, and can be queried using ZSTD_minCLevel().

From zstd.h

ZSTDLIB_API int ZSTD_minCLevel(void); /*!< minimum negative compression level allowed, requires v1.4.0+ */

P.S. : this function is

• 1.3.6: EXPERIMENTAL
• 1.3.8: Candidate API for promotion to stable status
• 1.4.0: stable

So this mean the minimal supported version should be raised to 1.4.0 (Apr 17, 2019)

[remicollet]

Additional note:

In version 5.x COMPRESSION_ZSTD_MIN was hardcoded as 1

From documentation:

  The library supports regular compression levels from 1 up to ZSTD_maxCLevel(),
  which is currently 22. Levels >= 20, labeled `--ultra`, should be used with
  caution, as they require more memory. The library also offers negative
  compression levels, which extend the range of speed vs. ratio preferences.
  The lower the level, the faster the speed (at the cost of compression).

So negative value (returned by ZSTD_minCLevel) have a special meaning.

[michael-grunder]

So this mean the minimal supported version should be raised to 1.4.0 (Apr 17, 2019)

I'll see if i can #ifdef around this.

[michael-grunder]

Should work now. For zstd < 1.4.0 we now just use 1 and 22.

[remicollet]

@michael-grunder you only need to protect ZSTD_minCLevel() usage
as ZSTD_maxCLevel() is always there (at least it is in 1.3.0 which is already required)