Support more powerful saved object filtering rules

[spalger]

Proposal: Support the filtering rules needed by the EUI SearchBar without coupling the effort to other DSL/AST/query lang initiatives by defining a basic filter schema that will allow basic boolean logic, filtering by terms, and ranges.

Example request body sent to POST /api/saved_objects/_find:

{
  experimental_filters: {
    must: [
      // numeric ranges
      { field: 'stars', gt: 3 },
      { field: 'followers', lte: 5 },

      // date ranges
      { field: 'created', gte: '2018-03-02T00:00:00-07:00', lt: '2018-03-03T00:00:00-07:00' },
      { field: 'created', gte: '2018-02-25T00:00:00-07:00', lt: '2018-03-01T00:00:00-07:00' },
      { field: 'created', lt: '2012-01-01T00:00:00-07:00' },

      // match, field not required
      { value: 'dashboard' },
      { field: 'active', value: true },

      // bools can be nested
      {
        must_some: [
          // today
          { field: 'created', gte: '2018-03-02T00:00:00-07:00', lt: '2018-03-03T00:00:00-07:00' },
          // yesterday
          { field: 'created', gte: '2018-03-01T00:00:00-07:00', lt: '2018-03-02T00:00:00-07:00' }
        ]
      }
    ],
    must_not: [
      { field: 'status', value: 'open' },
      { field: 'owner', value: 'dewey' },
      {
        must_some: [
          { field: 'tag', value: 'finance' },
          { field: 'tag', value: 'eng'  },
          { field: 'tag', value: 'ga'  }
        ]
      }
    ]
  }
}

---

Tasks:

• [savedObjects/mappings] limit valid type names #17511 prevent saved object types from starting with _
• Rename saved objects bulk_get and find endpoints #17512 rename api/saved_objects/bulk_get to api/saved_objects/_bulk_get and api/saved_objects/{type} (find) to api/saved_objects/_find
• [savedObjects] add experimental filter capabilities #17513 Support sending filters to POST api/saved_objects/_find

[spalger]

With the current API we could determine the type of the filters without the type: property, but doing that would make for some really lame error messages if the type of the filter can't be determined.

For example, if the user sends:

{ valu: 'foo' }

Then the best error message we'll be able to provide is probably something like:

Unable to determine type of filter { valu: 'foo' }

If instead they sent:

{ type: 'match', valu: 'foo' }

We could really easily send:

invalid property 'valu', valid options are 'field' and 'value'

edit: switched back to implicit type to avoid noise, prevent advertising the name "match", and because the error message below is good enough for my taste

[spalger]

I'm going to switch back to no type: property and instead rely on an error message like:

invalid property 'valu'. possible properties are 'value', 'gt', 'gte', 'lt', 'lte', 'must', 'must_not', and 'must_some'

We can always add the type: property back if we need it.