[backend/frontend] allow sorting groups by confidence level (#5756)

[labo-flg]

Proposed changes

• new enum value for GroupsOrdering
• in the elastic query,handle this complex sorting simply with dot syntax group_confidence_level.max_confidence: { order: 'asc' }
• to generalize, add a new field in schema attribute definition for objects: sortBy; if defined, it tells how to build the sorting key

Related issues

Closes #5756

Checklist

• [ ] I consider the submitted work as finished
• [ ] I tested the code for its functionality
• [ ] I wrote test cases for the relevant uses case
• [ ] I added/update the relevant documentation (either on github or on notion)
• [ ] Where necessary I refactored code to improve the overall quality

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 93.69369% with 7 lines in your changes are missing coverage. Please review.

Project coverage is 67.47%. Comparing base (0c8c045) to head (6151c2d). Report is 50 commits behind head on master.

Files	Patch %	Lines
...rm/opencti-graphql/src/schema/schema-attributes.ts	91.80%	5 Missing :warning:
...ncti-platform/opencti-graphql/src/utils/sorting.ts	93.54%	2 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6183      +/-   ##
==========================================
+ Coverage   67.30%   67.47%   +0.16%     
==========================================
  Files         541      542       +1     
  Lines       65192    65311     +119     
  Branches     5414     5595     +181     
==========================================
+ Hits        43879    44070     +191     
+ Misses      21313    21241      -72     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[labo-flg]

@richard-julien I've updated this PR after our latest discussions.

I did not use an array to define the possible sorting on an object, as it's impossible right now to do so without extensive modifications of the way sorting works API side + client side : we can only express a sorting key, part of an enum, that MUST correspond to an attribute key. We cannot use a new key name just for sorting.

I'm inclined to think adding an array would only add unnecessary complexity at this point.

EDIT: after some back and forth testing, we're settled on a simple approach: complex objects attribute, if meant to be used for sorting, shall define a sortBy property to tell in the schema how the sorting shall work. This field contains the path to a inner mapping, potentially deeply nested, and the type of the corresponding value.

This type is here for convenience, and we check at registration time that it corresponds to the given path. The goal is to avoid path/mapping resolving on every query (and this will never changed passed schema registration).