Add parsing to Significant Terms aggregations

[tlrx]

This pull request adds parsing methods for the SignificantStringTerms and SignificantLongTerms aggregations.

[javanna]

left a few minors, LGTM otherwise

[javanna]

can this happen in practice?

[tlrx]

No, I should have changed that.

[javanna]

same as above, just wondering if this can really happen, when can a key be null?

[tlrx]

No, we can return key.utf8ToString() directly.

[javanna]

++

[javanna]

is this method needed? I think it isn't used anywhere?

[tlrx]

It seems it's not used but I prefer to leave it in core - I saw something about it might be needed in scripted aggs or something. I'll try to figure this out, and if it's unused then I'll create a separate PR in core.

[javanna]

sounds good.

[tlrx]

Created #24714 to remove the method.

[javanna]

remove one of these empty lines? ;)

[javanna]

I think that to make this work as part of AggregationsTests you need to rename this method to setUp and remove before annotation?

[tlrx]

The AggregationsTests passed so I didn't catch it. I changed that, thanks.

[javanna]

ok weird that it worked. does the format have a default value in case this method is not called?

[tlrx]

No... but the output does not depend on the format (or heuristic) so a null format produces a valid XContent output that is parseable.

[javanna]

this one we set although it is never printed out as part of toXContent?

[tlrx]

We render the doc count which is in fact the subsetDf.

[cbuescher]

LGTM, I left a few minor comments that might either be addressed, ignored or handled as follow ups, as you prefer.

[cbuescher]

Could we reuse the constants used in InternalSignificantTerms by making them public? I think we did that elsewhere and also do this with the CommonFields.

[tlrx]

Sure - I changed them in core specially and after that I forgot to use them :/ Thanks

[cbuescher]

Should we lazily compute a bucketMap like in InternalMappedSignificantTerms and then be able reuse it when this method gets called many times? I have no strong opinions on this though.

[tlrx]

I don't have too... I tend to think that it can be done on caller's side if a lot of bucket are going to be retrieve by their keys. I'll add one for the sake of coherency with the internal implementations and other parsed aggregations.

[tlrx]

I also added a test about this method.

[cbuescher]

We render a subsetSize as the DOC_COUNT field in the surrounding aggregation, I'm not sure if this is equivalent with the bucket subset size but maybe it could be used here? Probably would need some checking with somebody who knows the aggregation better though.

[tlrx]

I'm not sure how they are related to be honest. Since we don't render the superset size and subset size I think it's ok to throw an unsupported operation exception here.

[tlrx]

Discussion that gives more background around where these fields come from: #5146 (comment)

[cbuescher]

I was wondering if getSuperset/SubsetSize is part of the Bucket interface but not rendered via the Rest response, should we either add rendering of these values to the bucket response or remove it from the interface to get equivalent behaviour of functionality of the transport client with the high level rest client here? I think this can be done in a separate issue though, maybe its not needed at all.

[tlrx]

Maybe @markharwood has an opinion on this?

[cbuescher]

I'm okay with the UnsupportedOperationException for now if we can track this question (whether we can reach consistency between the functionality the transport client provides via the SignificantTerms.Bucket interface with the rest response) in a separate issue

[tlrx]

This took me some time to wrap my head around this, but I finally created #24865 to address this.

[tlrx]

Thanks @javanna @cbuescher ! I updated a bit, would you like to have another look please?

[cbuescher]

Update looks good to me.

[tlrx]

Thanks @javanna @cbuescher !