Added filters aggregation

[uboness]

A multi-bucket aggregation where multiple filters can be defined (each filter defines a bucket). The buckets will collect all the documents that match their associated filter.

This aggregation can be very useful when one wants to compare analytics between different criterias. It can also be accomplished using multiple definitions of the single filter aggregation, but here, the user will only need to define the sub-aggregations only once.

Closes #6118

[uboness]

@rashidkpc @jpountz fyi

[jpountz]

I think the 2nd query should look for warning in the body instead of error?

[uboness]

indeed

[jpountz]

I like the way that this aggregation manages buckets (like the range agg). I left a couple of questions inlined.

[rashidkpc]

Love it, exactly what we needed.

[s1monw]

@uboness what's the status here? I remove the review tag for now...

[uboness]

I think it's pretty much ready... there's only a debate about the json structur... maybe @clintongormley can have a look

[s1monw]

+1 thanks @uboness

[clintongormley]

@uboness I think it should be:

{
     "aggs" : {
         "messages" : {
             "filters" : {
                 "errors" : { "query" : { "match" : { "body" : "error" } } },
                 "warnings" : { "query" : { "match" : { "body" : "error" } } }
             },
             "aggs" : { "monthly" : { "histogram" : { "field" : "timestamp", "interval" : "1M" } } }
         }
     }
 }

This fits nicely with the filter agg. It doesn't make sense to allow keyed because there is no intrinsic order to the keys of a hash in JSON. If you want the equivalent of keyed: false you could potentially support this format too:

{
     "aggs" : {
         "messages" : {
             "filters" : [
                 { "query" : { "match" : { "body" : "error" } } },
                 { "query" : { "match" : { "body" : "error" } } }
             ],
             "aggs" : { "monthly" : { "histogram" : { "field" : "timestamp", "interval" : "1M" } } }
         }
     }
 }

... but I think that's just providing options for the sake of it.

[uboness]

@clintongormley the idea behind the "keyed" version was to be future proof... it's consistent with other aggs, in the future if we'll need to add meta data to the application (which we actually working on doing in another PR #6465) it'll be mixed with the aggs data... and that's no good

[clintongormley]

@uboness PR #6465 will work happily with my example structure. The meta element isn't part of the agg body:

{
     "aggs" : {
         "messages" : {
             "filters" : {
                 "errors" : { "query" : { "match" : { "body" : "error" } } },
                 "warnings" : { "query" : { "match" : { "body" : "error" } } }
             },
             "meta": { "foo": "bar" },
             "aggs" : { "monthly" : { "histogram" : { "field" : "timestamp", "interval" : "1M" } } }
         }
     }
 }

The filter agg doesn't have space for any extra params in the body either:

{
     "aggs" : {
         "messages" : {
             "filter" : {"query" : { "match" : { "body" : "error" } } }
             "meta": { "foo": "bar" }
         }
     }
 }

So the only distinction between these filter and filters is the existence of a key, which predicates returning the result as {keyed: true} (as {keyed: false} would be meaningless here.

[uboness]

@clintongormley actually, you're right... my bad.. will work to see how it works out, thx

[colings86]

Closing as PR 6974 supersedes this