Standardize arrays and objects in querystring

[Shiranuit]

What does this PR do ?

request.getArray and request.getObject are now able to retrieve array and object from the query parameters.
Example of process for request.getArray:

• The retrieved value is an array -> returns it directly
• The retrieved value is a string:
  • If the request is an HTTP Request -> JSON Parse the string:
    • If the parsed result is an array returns it directly
    • If not throw an invalid_type error
  • If not throw an invalid_type error
• The retrieved value is something else -> throw an invalid_type error

The same process applies for getObject

Documentation on this behaviour has been added

There was some controller or pipe process that where splitting strings on , to obtain arrays, a new method has been added to the request object named getArrayLegacy, this method exist to ensure retrocompatibility, the method is deprecated and should not be used.

getArrayLegacy behaves pretty much like getArray but instead of throwing if the string cannot be parsed as a JSON Array
the string is simply splitted each time a , is encountered, to keep retrocompatibility.

getArrayLegacy process:

• The retrieved value is an array -> returns it directly
• The retrieved value is a string:
  • If the request is an HTTP Request -> JSON Parse the string:
    • If the parsed result is an array returns it directly
    • If not returns the string splitted on ,
  • If not returns the string splitted on ,
• The retrieved value is something else -> throw an invalid_type error

Tests have been added to cover this new cases

How should this be manually tested?

npm run test

Other changes

There was an undetected bug where calling getBodyBoolean in an HTTP Request was not returning the value of the field in the body but was returning true or false if the field was present or not.
This is now fixed.

[codecov]

Codecov Report

Merging #2342 (2813215) into 2-dev (8200a45) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##            2-dev    #2342   +/-   ##
=======================================
  Coverage   91.50%   91.50%           
=======================================
  Files         118      118           
  Lines        8064     8064           
=======================================
  Hits         7379     7379           
  Misses        685      685           

Impacted Files	Coverage Δ
lib/api/controllers/securityController.js	89.92% <100.00%> (ø)
lib/api/controllers/serverController.js	82.47% <100.00%> (ø)
lib/api/documentExtractor.js	87.35% <100.00%> (ø)

---

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 8200a45...2813215. Read the comment docs.

[alexandrebouthinon]

I'm quite a fan of this addition but for the sake of backwards compatibility, I would tend to do the opposite:

• Keep the old behavior for getObject and getArray.
• Create two new functions with the new behavior

[Shiranuit]

I'm quite a fan of this addition but for the sake of backwards compatibility, I would tend to do the opposite:

* Keep the old behavior for `getObject` and `getArray`.

* Create two new functions with the new behavior

I'm not sure to understand why would you do that ?
I mean getArray and getObject are the same has before they just have a another way of retrieving an array or object from a string.
deprecating those functions to add two new functions that do basicaly the same things with something more would mean replacing every getArray or getObject in the code of Kuzzle and everywhere it's used in the client code just to support something new that doesn't cause a breaking change

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication