[ML] Datafeed _preview should work with configs

[sophiec20]

The anomaly detection datafeed _preview currently requires that the datafeed has already been created. https://www.elastic.co/guide/en/elasticsearch/reference/7.11/ml-preview-datafeed.html

As an enhancement, it would be useful to preview source data before creating it. For example:

• To check if relevant data exists before creating the job - avoiding unnecessary object creation, unnecessary memory usage and in order to explain to users why no anomalies are being found
• To check that the expected data will be analysed - useful if trying to hand craft complex aggs or scripted fields or complex filters
• To simplify UI code which already performs a preview step of its own - will also make sure results match

Being able to preview source data by supplying a potential config, also aligns with POST _ml/data_frame/analytics/_explain and POST _transform/_preview, both of which can be performed prior to creating the job/transform.

[elasticmachine]

Pinging @elastic/ml-core (Team:ML)

[benwtrent]

In the UI wizard, neither the job nor the datafeed are created. So, the API will have to accept both configurations. Consequently, I am wondering if this should not be under the datafeed url but instead is an anomaly_detection/_preview. The user will have to provide BOTH configurations and we do prefer to think of datafeeds as dependent on anomaly_detection jobs and not the other way around.

Something like:

POST|GET _ml/anomaly_detectors/_preview
{
  "job_config": {...},
  "datafeed_config":{...}
}

Then you can also do something like:

POST|GET _ml/anomaly_detectors/<job_id>/_preview
{
  "datafeed_config":{...}
}

[dimitris-athanasiou]

I think it makes sense to keep it under datafeeds. The response of these two APIs should be the same. And it is really a preview of what the datafeed sends to the job. Previewing an anomaly detector could imply more things.

I think the request still makes sense to expect a job_config and a datafeed_config. It would also be nice if it took in a job_id instead of a job_config so that it works with a job that has already been created and a datafeed that has not been created yet. That's a nice-to-have btw, definitely not a must.