Check for SDK compatibility against current Kuzzle version

[Aschen]

What does this PR do ?

v1: #1494

Now Kuzzle will check the volatile.sdkName header to ensure that the current SDK is compatible against the current Kuzzle version.

For Kuzzle v1 SDKs, the sdkVersion property is present. So when the property is present, we assume that the SDK is incompatible.

For Kuzzle v2 SDKs, a compatibility matrix has been added. It's checking the volatile.sdkVersion property and works with simplified semver ranges.

Example compat matrix:

{
  "js": ">=7" // this version of Kuzzle is compatible with the JS SDKs beginning at the 7.x.x version
}

Example sdkName volatile property: js@7.4.2

Other changes

• upgrade Elasticsearch version to 7.4.0

[codecov]

Codecov Report

Merging #1495 into 2-dev will increase coverage by 0.02%.
The diff coverage is 96.87%.

@@            Coverage Diff             @@
##            2-dev    #1495      +/-   ##
==========================================
+ Coverage   92.82%   92.85%   +0.02%     
==========================================
  Files          98       97       -1     
  Lines        6678     6621      -57     
==========================================
- Hits         6199     6148      -51     
+ Misses        479      473       -6

Impacted Files	Coverage Δ
lib/api/controllers/funnelController.js	95.76% <96.87%> (+0.07%)	⬆️
lib/api/core/entrypoints/index.js	98.88% <0%> (-0.01%)	⬇️
lib/api/core/janitor.js	89% <0%> (ø)	⬆️
lib/api/core/entrypoints/protocols/socketio.js
lib/api/core/plugins/pluginsManager.js	89.62% <0%> (+0.07%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3b72934...cc83c9b. Read the comment docs.

[scottinet]

Why not using semver, which is already included in our package.json?

The way it's currently coded, the compatibility matrix is misleading. I, for one, would have expected a semver range, and I expect to be able to enter something like >=7 <9 for instance, which is a probable value.

[Aschen]

I choose to use some kind of simplified semver range for now because semver is really slow and this method is called whenever Kuzzle receive a request.

Semver x 176,414 ops/sec ±4.15% (85 runs sampled)
Manual: only major x 776,075,210 ops/sec ±2.42% (90 runs sampled)

We won't need support for this kind of range (>=7 <9) until v3.

Do you think it's unnecessary ?

[scottinet]

Indeed, this is slow.

My real problem is the syntax similarity with semver, I find that very misleading for future maintenance.

Since the matrix is internal, I think that using a custom format that has nothing to do with semver might be a better idea.

Something like:

{
  "js": { "min": 7 },
  "csharp": { "max": 2},
  "cpp": { "max": 2},
  "java": { "max": 3},
  "android": { "max": 5},
  "go": { "max": 3},
  "php": { "max": 4}
}

Of course, we would be able to have both a min and a max value. This should make the version check even faster while unambiguously being different from semver.

What do you think?

[scottinet]

you need to remove the auth-local plugin update from this PR

apart from that: 👍

[Aschen]

you need to remove the auth-local plugin update from this PR

apart from that: +1

Done @scottinet