Migrate from CAS to Lua(or Javascript) scripts for Redis integration

[vladimir-bukhtoyarov]

Motivation:
In order to increase scalability and latency, because CAS is not scalled for contended keys.

The math problem:
Redis support only legacy 5.1 Lua interpreter without support of 64 bits integer, and only double arifmetic is available. While currently CAS uses Longs provided by JVM. It makes impossible for some scenarios to write unit tests that checks that nothing changed after migration, because double arithmetic is not accurate for some corner cases.

Proposed solutions of math problem:

• Use some thirdparty implementations of big-numbers like https://github.com/ennorehling/euler/blob/master/BigNum.lua Consaderations - perfomance penalty.
• Implement alternative math in java(work is partially done already, see BucketStateIEEE754.java ) and test Java and Lua version with same math. Cons - accuracy will degradate for Redis integration.

[vladimir-bukhtoyarov]

Unfortunatelly, I was unable to find any mature library for Lua 5.1 that supports BigIntegers. All publically available solutions like https://github.com/ennorehling/euler/blob/master/BigNum.lua or https://github.com/empyreuma/bigint.lua were failed to pass my tests. So, there is only one way to support Lua - forget about precision.

[vladimir-bukhtoyarov]

Looks that it is better to wait Javascript API to be generally available and instead of hacking with legacy Lua.
https://redis.io/docs/interact/programmability/triggers-and-functions/concepts/javascript_api/

[vladimir-bukhtoyarov]

A docker container with Javascript support is already available https://hub.docker.com/r/redislabs/redisgears
Javascript API should be merged to main Redis line in version 8.0

[vladimir-bukhtoyarov]

It worth to consider to try Kotlin-JS instead of writting js code from scratch. In the theory this should allow to reduce the efforts in following points:

• It is possible to get java code as is and convert to Kotlin with minimum(in theory) fixes.
• It is possible to reuse already written junit/spock unit tests with minimum generalization.

Some additional thought about trying Kotlin described there #283

[vladimir-bukhtoyarov]

Also, it needs to try TeamVM, it looks more promising than kotlinjs, because works with bytecode, as result it is not nessesary to copy something into kotlin.