Temporarily disable fsst and fast-pfor

[springmeyer]

Two reasons for this:

• To be able to get the java converter running on non-windows platforms
• To lower the barrier to writing encoders that will not easily have access to these encodings in their first versions

Note: commenting code I think is the right approach right now because it's fast and will allow for things to be brought back quickly (when the time is right). But of course it be ideal to refactor the code to make the fast.dll only load if needed, but that is beyond my java expertise.

[mactrem]

The prototype java wrapper for the Fsst encoding is now checked in thanks to @FF-98 see https://github.com/mactrem/cov-tiles/tree/main/encodings/fsst/java/fsst-wrapper. What's missing is a automated build of the native C++ fsst source library from the https://github.com/cwida/fsst repo which could be included for example as a git submodule. Do you think we could integrate a platform independent build with less effort so that there is no need to exclude the fsst encoding? Because we now also have a prototype js fsst and a Js FastPfor decoder thanks to @etnav and @Gh0stD3x, so we can use this encodings for the POC MLT js decoder

[springmeyer]

What's missing is a automated build of the native C++ fsst source library from the https://github.com/cwida/fsst repo which could be included for example as a git submodule.

Great, I've ticketed this at #37.

I've started working on the native build + JNI fixes needed to get the wrapper compiling on unix, but it's not quite working yet. I should be able to get this working by early next week.

Do you think we could integrate a platform independent build with less effort so that there is no need to exclude the fsst encoding?

Yes.

Because we now also have a prototype js fsst and a Js FastPfor decoder thanks to @etnav and @Gh0stD3x, so we can use this encodings for the POC MLT js decoder

Great.

So, I'll close this then with the hope that we can get things working early next week. If not, we can revisit again.