[FEATURE][ML] User config appropriate permission checks on creating/running analytics

[benwtrent]

This PR adds headers to the DataFrameAnalyticsConfig and utilizes those headers when running the analysis.

NOTE:
CreateIndexAction.NAME != create_index permission. Had a long chat with the security folks and apparently CreateIndexAction.NAME is treated as a prefix wildcard, where as create_index is that specific permission for that index pattern.

When creating a role via the UI, the permission that auto-populates is create_index, and since that permission is enough (verified through testing), I opted to use it instead of the more expansive one.

There were many calls that were simply client.execute but these will all fail when security is turned on due to the default user not having any perms. I used the user's headers where I thought appropriate and changed the calls to be from the ML_ORIGIN

[elasticmachine]

Pinging @elastic/ml-core

[dimitris-athanasiou]

This looks good to me apart from a couple of minor comments. But I would also prefer for this to be reviewed by @droberts195 as well as Dave is has better understanding of the security framework.

[droberts195]

Looks good. I just left a few minor comments.

[dimitris-athanasiou]

Shall we also use this.config = Collections.unmodifiableMap(config.config)?

[droberts195]

To avoid the nested wrapping problem with Collections.unmodifiableMap we would have to use this.config = Collections.unmodifiableMap(new HashMap<>(config.config)).

However, it would be better to use Collections.unmodifiableMap in the two other constructors instead, and then this one can simply copy the reference safe in the knowledge that the other map is unmodifiable. If we make the class immutable like this then there's actually no need for this copy constructor at all...

[dimitris-athanasiou]

LGTM