Email/Query expose supported collation in session capabilities object

[remk]

Why

The sort comparator accept a collation to define how the string values are compared. If not defined in the request the collation is the default one from the server.

How

collation: String (optional; default is server dependent) The identifier, as registered in the collation registry defined in [@!RFC4790], for the algorithm to use when comparing the order of strings. The algorithms the server supports are advertised in the capabilities object returned with the Session object (see Section 2).

If omitted, the default algorithm is server-dependent, but:

    It MUST be unicode-aware.
    It MAY be selected based on an Accept-Language header in the request (as defined in [@!RFC7231], Section 5.3.5), or out-of-band information about the user’s language/locale.
    It SHOULD be case insensitive where such a concept makes sense for a language/locale. Where the user’s language is unknown, it is RECOMMENDED to follow the advice in Section 5.2.3 of [@!RFC8264].

The “i;unicode-casemap” collation [@!RFC5051] and the Unicode Collation Algorithm (http://www.unicode.org/reports/tr10/) are two examples that fulfil these criterion and provide reasonable behaviour for a large number of languages.

for the time being we will only support the “i;unicode-casemap” collation

TO GROOM

• Do we support unicode sorting in elastic search ? Should use specific analysers with the ICU plugin : https://www.elastic.co/guide/en/elasticsearch/guide/current/sorting-collations.html#case-insensitive-sorting

DOD

• write an integration test demonstrating that the capabilities field of the session object contains the list of supported collations

  "collationAlgorithms": [
      "i;unicode-casemap"
    ]

[chibenwa]

see if we need to accept more collation algorithms for example "i;ascii-numeric", "i;ascii-casemap"

IMO no

[chibenwa]

The DOD is already implemented (see SessionRoutesContract)