[DOCS] Moves ml folder from x-pack/docs to docs (#33248)

Author: lcawl

docs/build.gradle

@@ -19,6 +19,12 @@
 
 apply plugin: 'elasticsearch.docs-test'
 
+/* List of files that have snippets that require a gold or platinum licence 
+and therefore cannot be tested yet... */
+buildRestTests.expectedUnconvertedCandidates = [
+        'reference/ml/transforms.asciidoc',
+]
+
 integTestCluster {
   /* Enable regexes in painless so our tests don't complain about example
    * snippets that use them. */

x-pack/docs/en/ml/aggregations.asciidoc renamed to docs/reference/ml/aggregations.asciidoc

@@ -41,7 +41,7 @@ PUT _xpack/ml/anomaly_detectors/farequote
 }
 ----------------------------------
 // CONSOLE
-// TEST[setup:farequote_data]
+// TEST[skip:setup:farequote_data]
 
 In this example, the `airline`, `responsetime`, and `time` fields are
 aggregations.
@@ -90,7 +90,7 @@ PUT _xpack/ml/datafeeds/datafeed-farequote
 }
 ----------------------------------
 // CONSOLE
-// TEST[setup:farequote_job]
+// TEST[skip:setup:farequote_job]
 
 In this example, the aggregations have names that match the fields that they
 operate on. That is to say, the `max` aggregation is named `time` and its

x-pack/docs/en/ml/categories.asciidoc renamed to docs/reference/ml/categories.asciidoc

@@ -44,6 +44,7 @@ PUT _xpack/ml/anomaly_detectors/it_ops_new_logs
 }
 ----------------------------------
 //CONSOLE
+// TEST[skip:needs-licence]
 <1> The `categorization_field_name` property indicates which field will be
 categorized.
 <2> The resulting categories are used in a detector by setting `by_field_name`,
@@ -127,6 +128,7 @@ PUT _xpack/ml/anomaly_detectors/it_ops_new_logs2
 }
 ----------------------------------
 //CONSOLE
+// TEST[skip:needs-licence]
 <1> The
 {ref}/analysis-pattern-replace-charfilter.html[`pattern_replace` character filter]
 here achieves exactly the same as the `categorization_filters` in the first
@@ -193,6 +195,7 @@ PUT _xpack/ml/anomaly_detectors/it_ops_new_logs3
 }
 ----------------------------------
 //CONSOLE
+// TEST[skip:needs-licence]
 <1> Tokens basically consist of hyphens, digits, letters, underscores and dots.
 <2> By default, categorization ignores tokens that begin with a digit.
 <3> By default, categorization also ignores tokens that are hexadecimal numbers.

x-pack/docs/en/ml/configuring.asciidoc renamed to docs/reference/ml/configuring.asciidoc

@@ -36,20 +36,20 @@ The scenarios in this section describe some best practices for generating useful
 * <<ml-configuring-transform>>
 * <<ml-configuring-detector-custom-rules>>
 
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/ml/customurl.asciidoc
+:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/docs/reference/ml/customurl.asciidoc
 include::customurl.asciidoc[]
 
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/ml/aggregations.asciidoc
+:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/docs/reference/ml/aggregations.asciidoc
 include::aggregations.asciidoc[]
 
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/ml/categories.asciidoc
+:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/docs/reference/ml/categories.asciidoc
 include::categories.asciidoc[]
 
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/ml/populations.asciidoc
+:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/docs/reference/ml/populations.asciidoc
 include::populations.asciidoc[]
 
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/ml/transforms.asciidoc
+:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/docs/reference/ml/transforms.asciidoc
 include::transforms.asciidoc[]
 
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/ml/detector-custom-rules.asciidoc
+:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/docs/reference/ml/detector-custom-rules.asciidoc
 include::detector-custom-rules.asciidoc[]

x-pack/docs/en/ml/customurl.asciidoc renamed to docs/reference/ml/customurl.asciidoc

@@ -106,7 +106,7 @@ POST _xpack/ml/anomaly_detectors/sample_job/_update
 }
 ----------------------------------
 //CONSOLE
-//TEST[setup:sample_job]
+//TEST[skip:setup:sample_job]
 
 When you click this custom URL in the anomalies table in {kib}, it opens up the
 *Discover* page and displays source data for the period one hour before and 

x-pack/docs/en/ml/detector-custom-rules.asciidoc renamed to docs/reference/ml/detector-custom-rules.asciidoc

@@ -39,6 +39,7 @@ PUT _xpack/ml/filters/safe_domains
 }
 ----------------------------------
 // CONSOLE
+// TEST[skip:needs-licence]
 
 Now, we can create our job specifying a scope that uses the `safe_domains` 
 filter for the `highest_registered_domain` field:
@@ -70,6 +71,7 @@ PUT _xpack/ml/anomaly_detectors/dns_exfiltration_with_rule
 }
 ----------------------------------
 // CONSOLE
+// TEST[skip:needs-licence]
 
 As time advances and we see more data and more results, we might encounter new 
 domains that we want to add in the filter. We can do that by using the 
@@ -83,7 +85,7 @@ POST _xpack/ml/filters/safe_domains/_update
 }
 ----------------------------------
 // CONSOLE
-// TEST[setup:ml_filter_safe_domains]
+// TEST[skip:setup:ml_filter_safe_domains]
 
 Note that we can use any of the `partition_field_name`, `over_field_name`, or 
 `by_field_name` fields in the `scope`.
@@ -123,6 +125,7 @@ PUT _xpack/ml/anomaly_detectors/scoping_multiple_fields
 }
 ----------------------------------
 // CONSOLE
+// TEST[skip:needs-licence]
 
 Such a detector will skip results when the values of all 3 scoped fields
 are included in the referenced filters.
@@ -166,6 +169,7 @@ PUT _xpack/ml/anomaly_detectors/cpu_with_rule
 }
 ----------------------------------
 // CONSOLE
+// TEST[skip:needs-licence]
 
 When there are multiple conditions they are combined with a logical `and`.
 This is useful when we want the rule to apply to a range. We simply create
@@ -205,6 +209,7 @@ PUT _xpack/ml/anomaly_detectors/rule_with_range
 }
 ----------------------------------
 // CONSOLE
+// TEST[skip:needs-licence]
 
 ==== Custom rules in the life-cycle of a job
 

x-pack/docs/en/ml/functions.asciidoc renamed to docs/reference/ml/functions.asciidoc

@@ -59,6 +59,7 @@ PUT _xpack/ml/anomaly_detectors/example1
 }
 --------------------------------------------------
 // CONSOLE
+// TEST[skip:needs-licence]
 
 This example is probably the simplest possible analysis. It identifies
 time buckets during which the overall count of events is higher or lower than
@@ -86,6 +87,7 @@ PUT _xpack/ml/anomaly_detectors/example2
 }
 --------------------------------------------------
 // CONSOLE
+// TEST[skip:needs-licence]
 
 If you use this `high_count` function in a detector in your job, it
 models the event rate for each error code. It detects users that generate an
@@ -110,6 +112,7 @@ PUT _xpack/ml/anomaly_detectors/example3
 }
 --------------------------------------------------
 // CONSOLE
+// TEST[skip:needs-licence]
 
 In this example, the function detects when the count of events for a
 status code is lower than usual.
@@ -136,6 +139,7 @@ PUT _xpack/ml/anomaly_detectors/example4
 }  
 --------------------------------------------------
 // CONSOLE
+// TEST[skip:needs-licence]
 
 If you are analyzing an aggregated `events_per_min` field, do not use a sum
 function (for example, `sum(events_per_min)`). Instead, use the count function
@@ -200,6 +204,7 @@ PUT _xpack/ml/anomaly_detectors/example5
 }
 --------------------------------------------------
 // CONSOLE
+// TEST[skip:needs-licence]
 
 If you use this `high_non_zero_count` function in a detector in your job, it
 models the count of events for the `signaturename` field. It ignores any buckets
@@ -253,6 +258,7 @@ PUT _xpack/ml/anomaly_detectors/example6
 }
 --------------------------------------------------
 // CONSOLE
+// TEST[skip:needs-licence]
 
 This `distinct_count` function detects when a system has an unusual number
 of logged in users. When you use this function in a detector in your job, it
@@ -278,6 +284,7 @@ PUT _xpack/ml/anomaly_detectors/example7
 }
 --------------------------------------------------
 // CONSOLE
+// TEST[skip:needs-licence]
 
 This example detects instances of port scanning. When you use this function in a
 detector in your job, it models the distinct count of ports. It also detects the

x-pack/docs/en/ml/functions/count.asciidoc renamed to docs/reference/ml/functions/count.asciidoc

@@ -47,6 +47,7 @@ PUT _xpack/ml/anomaly_detectors/example1
 }
 --------------------------------------------------
 // CONSOLE
+// TEST[skip:needs-licence]
 
 If you use this `lat_long` function in a detector in your job, it
 detects anomalies where the geographic location of a credit card transaction is
@@ -98,6 +99,6 @@ PUT _xpack/ml/datafeeds/datafeed-test2
 }
 --------------------------------------------------
 // CONSOLE
-// TEST[setup:farequote_job]
+// TEST[skip:setup:farequote_job]
 
 For more information, see <<ml-configuring-transform>>.

x-pack/docs/en/ml/functions/geo.asciidoc renamed to docs/reference/ml/functions/geo.asciidoc

@@ -51,14 +51,11 @@ PUT _xpack/ml/anomaly_detectors/population
 }
 ----------------------------------
 //CONSOLE
+// TEST[skip:needs-licence]
 <1> This `over_field_name` property indicates that the metrics for each user (
   as identified by their `username` value) are analyzed relative to other users
   in each bucket.
 
-//TO-DO: Per sophiec20 "Perhaps add the datafeed config and add a query filter to
-//include only workstations as servers and printers would behave differently
-//from the population
-
 If your data is stored in {es}, you can use the population job wizard in {kib}
 to create a job with these same properties. For example, the population job
 wizard provides the following job settings:

x-pack/docs/en/ml/functions/info.asciidoc renamed to docs/reference/ml/functions/info.asciidoc

@@ -28,7 +28,7 @@ request stops the `feed1` {dfeed}:
 POST _xpack/ml/datafeeds/datafeed-total-requests/_stop
 --------------------------------------------------
 // CONSOLE
-// TEST[setup:server_metrics_startdf]
+// TEST[skip:setup:server_metrics_startdf]
 
 NOTE: You must have `manage_ml`, or `manage` cluster privileges to stop {dfeeds}.
 For more information, see <<security-privileges>>.
@@ -49,6 +49,7 @@ If you are upgrading your cluster, you can use the following request to stop all
 POST _xpack/ml/datafeeds/_all/_stop
 ----------------------------------
 // CONSOLE
+// TEST[skip:needs-licence]
 
 [float]
 [[closing-ml-jobs]]
@@ -67,7 +68,7 @@ example, the following request closes the `job1` job:
 POST _xpack/ml/anomaly_detectors/total-requests/_close
 --------------------------------------------------
 // CONSOLE
-// TEST[setup:server_metrics_openjob]
+// TEST[skip:setup:server_metrics_openjob]
 
 NOTE: You must have `manage_ml`, or `manage` cluster privileges to stop {dfeeds}.
 For more information, see <<security-privileges>>.
@@ -86,3 +87,4 @@ all open jobs on the cluster:
 POST _xpack/ml/anomaly_detectors/_all/_close
 ----------------------------------
 // CONSOLE
+// TEST[skip:needs-licence]