Natural filtering

[bdunogier]

The collection field for a type (articles, blogPosts) will expose an argument
for each searchable field:

{
  media {
    images(name: "~norway") {
      _name
    }
  }
  content {
    products(price: "> 20", gluten: false) {
      _name
    }
  }
}

Supported operators (as first characters of the string): ~ (like, with automatic wildcards), <, >, <=, >=).

TODO

• Add syntax for not (!~norway)
• Accept array of values arguments where at least one value has an operator as a OR.
• Handle date fields (publicationDate: "< 2018/11/10")
• Refactor fields filters processing, and ideally unit test it.
• Figure out what's "searchable" when the LSE is used. It is actually detected when converting the criteria using the LegacyConverter's getIndexColumn() method, that returns false for these fields. It may have to be taken into account at schema generation's time, but the schema will then depend on the environment / search engine.
• Reintroduce non-field filters (fulltext, parent location...), probably prefixed with _
• Add fields to sortBy as well
• Consider an alternative, more explicit, operator handling (see paragraph below)

Alternative, explicit operator handling

Concatenate fields identifiers with applicable operators "phrases":

filter: {
  titleLike: "foo", 
  priceLowerThan: 25
}

Each of them can be prefixed with not:

filter: {titleNotLike: "foo"}

Custom criteria can then be mapped to their own operator:

filter: {
  locationDistanceFromGreaterThan($lat, $lon, $distance)

Alternative 2 (sounds more flexible): each field definition is an object with the operators as fields, and the value as arguments:

filter: {
  name { like($name) },
  locationDistanceFrom($lat, $lon) { lowerThan($distance) }
}

Unfortunately, this syntax isn't valid as input-object fields can't have arguments