Email/query sort by size/from/to/subject

[remk]

WHY

With the new specifications as an user i want to be able to sort by 'size' and 'from', 'to' and 'subject' properties, like this :

[[ "Email/query",{
  "accountId": "ue150411c",
  "sort" : {
      "size": "size",
      "isAscending": true
}
}, "0" ]]

HOW

• accept the 'size' value in the 'propertyField' of the sort field of the request.
• accept the 'from' value in the 'propertyField' of the sort field of the request.
• accept the 'to' value in the 'propertyField' of the sort field of the request.
• accept the 'subject' value in the 'propertyField' of the sort field of the request.

DOD

• write an integration test demonstrating the sorting of the result by 'size' in both ascending and descending order
• write an integration test demonstrating the sorting of the result by 'from' in both ascending and descending order
• write an integration test demonstrating the sorting of the result by 'to' in both ascending and descending order
• write an integration test demonstrating the sorting of the result by 'subject' in both ascending and descending order
• write an integration test demonstrating that a unsupportedSort method error is return in case of unknown collation

[chibenwa]

Which collation are supported?

(important for text fields!)

A Comparator has the following properties:

    property: String The name of the property on the Foo objects to compare.
    isAscending: Boolean (optional; default: true) If true, sort in ascending order. If false, reverse the comparator’s results to sort in descending order.

    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.

    When the property being compared is not a string, the collation property is ignored, and the following comparison rules apply based on the type. In ascending order:
        Boolean: false comes before true.
        Number: A lower number comes before a higher number.
        Date/UTCDate: The earlier date comes first.

The Comparator object may also have additional properties as required for specific sort operations defined in a type’s /query method.