[ML] 'prediction_field_name' accepts values that clash with already existing fields

[dolaru]

Found in 7.5.0

Currently, the value of the prediction_field_name parameter for analytics jobs accepts any string value as a field name.

This means the user can put in a field name that clashes with something we're already using under the ml key when writing results (e.g.is_training). If a user does so, the analytics job fails due to mapping conflicts at the result writing stage.

This kind of situation can be avoided by failing during job creation if prediction_field_name matches any child key from the ml field mapping we use for the results index.

[elasticmachine]

Pinging @elastic/ml-core (:ml)

[przemekwitek]

This is good catch!

Currently, for classification there are three such fields: prediction_probability, is_training and top_classes.
For regression there is one: is_training.

Please note that currently (it may change in the future) we do not have an upfront defined mapping for the results. Therefore, if we want to fail the job creation, we'd have to hardcode the fields listed above in the job creation code (Java). This introduces duplication between C++ and Java as now every new field emitted by C++ code would have to be copied to the field name blacklist in Java.
@dimitris-athanasiou: Please LMK if you think such a duplication is acceptable (at least as a short-term remediated for this bug).

[przemekwitek]

As of elastic/ml-cpp#861 the check is done in C++