lib/gis: Update lz4 library to latest upstream version (v1.10.0)

[ymdatta]

Sync lz4 library with the upstream version v 1.10.0.

This has fixes simplifying and making the library robust in multiple areas.

This also fixes the initial null pointer arithmetic error found by cppcheck, which prompted syncing with the upstream library for new fixes and updates.

[metzm]

Please check first if the issue is resolved in upstream https://github.com/lz4/lz4
The preferred solution would be to update the local copy in lib/gis/ to the latest release of LZ4

[ymdatta]

@metzm : Thanks for pointing it out. I didn't realize that it was an external library and believed we were maintaining a local version.

I have checked the code in the upstream and indeed they have fixed this issue! I can update this PR to have changes which sync our version to the upstream.

[ymdatta]

Some testing done as part of the library update:

1. Manually checked function calls to LZ4 library in cmprlz4.c to make sure that there is no mismatch to function signatures in the new version.
2. Compiled the code to make sure it's not erroring out.

Only changes come in the form of clang format check specific changes to the upstream code.

@metzm : Let me know if I have missed anything or can improve patch set in some way. Thanks!

[nilason]

@metzm or any one with knowledge: Do we have test that limits the risk of regression of this?

[neteler]

How about borrowing a test from https://github.com/lz4/lz4/tree/dev/tests/?

[ymdatta]

Some things I want to highlight:

• I am looking at lz4 library history in our codebase and in the two previous instances where the library was upgraded, it was done without any regression tests.
• I am not sure if we can adopt lz4 tests as regression tests. Because, the APIs we are using: LZ4_compressBound, LZ4_compress_default, and LZ4_decompress_safe are not being directly used anywhere in the lz4 tests.
• I observed that these APIs had the same interface between older and upgraded version. Release notes indicate that none of these APIs have been deprecated or are backwards incompatible now. So, I think we should be good.

[nilason]

Some things I want to highlight:

• I am looking at lz4 library history in our codebase and in the two previous instances where the library was upgraded, it was done without any regression tests.

If I'm not mistaken, that was the time before CI run tests and I'm still not sure whether we have tests for the different supported compression methods. It may have been tested manually by committer with the former updates.

• I am not sure if we can adopt lz4 tests as regression tests. Because, the APIs we are using: LZ4_compressBound, LZ4_compress_default, and LZ4_decompress_safe are not being directly used anywhere in the lz4 tests.

In practice we can, see r.compress for setting and using different compression methods.

• I observed that these APIs had the same interface between older and upgraded version. Release notes indicate that none of these APIs have been deprecated or are backwards incompatible now. So, I think we should be good.

All being said, my hunch is that it is probably safe too. @metzm what is your opinion on this?

[metzm]

I agree that using r.compress to test different compression methods should be sufficient.

The LZ4 API is very similar, often identical to the APIs of the other compression methods used in GRASS. I am not expecting any changes here in the default functions as used by us because the have been established for many years in different projects.

We are having a local copy because the code base is so small and consists of only two files. Therefore I decided back then to simply add these two files to lib/gis/ instead of adding another external dependency to the Make system.