REST tests for moving_fn agg

[nik9000]

This expands on the REST layer tests for the moving_fn agg asserting the results of the various moving functions, some failure cases, and some access edge cases. These tests buy us backwards compatibility tests and, eventually, forwards compatibility testing.

[elasticsearchmachine]

Pinging @elastic/es-analytics-geo (Team:Analytics)

[nik9000]

These tests were in the lang-painless module which is a little confusing, but it's because we can't really test the fun edge cases of the agg without a scripting language. We have unit tests that do that in the server project but we'd like the forwards and backwards tests that we get from doing it with painless. I don't know of a better place for this, but if anyone has any ideas I'm happy to move it.

[martijnvg]

LGTM

These tests were in the lang-painless module which is a little confusing,

This shouldn't block this PR, but could we move these tests to rest-api-spec/src/yamlRestTest/resources/rest-api-spec/test/search.aggregation ? I think when running these yaml tests we run we the default distribution (which has lang-painless)? And other aggregation yaml tests are here as well.

Another idea that is way outside of the scope of this PR, we could have an analytics module. This module could contain almost all aggregations and then server only contains aggregation infrastructure. This way the module can have its own yaml test task and we could add the lang-painless module as an integration test dependency to this new module. This will have other benefits, such as make server module smaller and make it easier to run aggregation tests. Just an idea, that I wanted to share here...

[not-napoleon]

LGTM. Do you think we should leave one or two tests in server with a comment about where to find the rest of them? Just so someone looking at the "usual place" doesn't think this is untested?

[nik9000]

Do you think we should leave one or two tests in server with a comment about where to find the rest of them? Just so someone looking at the "usual place" doesn't think this is untested?

Yeah, probably.

This shouldn't block this PR, but could we move these tests to rest-api-spec/src/yamlRestTest/resources/rest-api-spec/test/search.aggregation ? I think when running these yaml tests we run we the default distribution (which has lang-painless)? And other aggregation yaml tests are here as well.

Another idea that is way outside of the scope of this PR, we could have an analytics module. This module could contain almost all aggregations and then server only contains aggregation infrastructure

The last time I checked they didn't have painless. I'll have another look though. The submodule is a neat idea though.

[nik9000]

The last time I checked they didn't have painless. I'll have another look though. The submodule is a neat idea though.

            stack_trace: "java.lang.IllegalArgumentException: script_lang not supported [painless]\n\

[martijnvg]

stack_trace: "java.lang.IllegalArgumentException: script_lang not supported [painless]\n\

:(
Thinking more about this, another complication here is that rest api spect yaml tests are reused several times running ES in different kind of setups.