[DOCS] [1 of 5] Replace "// CONSOLE" comments with [source,console]

docs/reference/administering/backup-and-restore-security-config.asciidoc

@@ -75,7 +75,7 @@ It is preferable to have a <<backup-security-repos, dedicated repository>> for
 this special index. If you wish, you can also snapshot the system indices for other {stack} components to this repository. 
 +
 --
-[source,js]
+[source,console]
 -----------------------------------
 PUT /_snapshot/my_backup
 {
@@ -85,7 +85,6 @@ PUT /_snapshot/my_backup
   }
 }
 -----------------------------------
-// CONSOLE
 
 The user calling this API must have the elevated `manage` cluster privilege to
 prevent non-administrators exfiltrating data.
@@ -99,15 +98,14 @@ The following example creates a new user `snapshot_user` in the
 {stack-ov}/native-realm.html[native realm], but it is not important which
 realm the user is a member of:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/user/snapshot_user
 {
   "password" : "secret",
   "roles" : [ "snapshot_user" ]
 }
 --------------------------------------------------
-// CONSOLE
 // TEST[skip:security is not enabled in this fixture]
 
 --
@@ -118,15 +116,14 @@ POST /_security/user/snapshot_user
 The following example shows how to use the create snapshot API to backup
 the `.security` index to the `my_backup` repository:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 PUT /_snapshot/my_backup/snapshot_1
 {
   "indices": ".security",
   "include_global_state": true <1>
 }
 --------------------------------------------------
-// CONSOLE
 // TEST[continued]
 
 <1> This parameter value captures all the persistent settings stored in the
@@ -189,18 +186,16 @@ the {security-features}.
 To restore your security configuration from a backup, first make sure that the
 repository holding `.security` snapshots is installed:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_snapshot/my_backup
 --------------------------------------------------
-// CONSOLE
 // TEST[continued]
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_snapshot/my_backup/snapshot_1
 --------------------------------------------------
-// CONSOLE
 // TEST[continued]
 
 Then log into one of the node hosts, navigate to {es} installation directory,

docs/reference/aggregations/bucket/adjacency-matrix-aggregation.asciidoc

@@ -28,7 +28,7 @@ other than the default of the ampersand.
 
 Example:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 PUT /emails/_bulk?refresh
 { "index" : { "_id" : 1 } }
@@ -54,7 +54,6 @@ GET emails/_search
   }
 }
 --------------------------------------------------
-// CONSOLE
 
 In the above example, we analyse email messages to see which groups of individuals 
 have exchanged messages.

docs/reference/aggregations/bucket/autodatehistogram-aggregation.asciidoc

@@ -10,7 +10,7 @@ The buckets field is optional, and will default to 10 buckets if not specified.
 
 Requesting a target of 10 buckets.
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /sales/_search?size=0
 {
@@ -24,7 +24,6 @@ POST /sales/_search?size=0
     }
 }
 --------------------------------------------------
-// CONSOLE
 // TEST[setup:sales]
 
 ==== Keys
@@ -37,7 +36,7 @@ date string using the format specified with the `format` parameter:
 TIP: If no `format` is specified, then it will use the first date
 <<mapping-date-format,format>> specified in the field mapping.
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /sales/_search?size=0
 {
@@ -52,7 +51,6 @@ POST /sales/_search?size=0
     }
 }
 --------------------------------------------------
-// CONSOLE
 // TEST[setup:sales]
 
 <1> Supports expressive date <<date-format-pattern,format pattern>>
@@ -119,7 +117,7 @@ Time zones may either be specified as an ISO 8601 UTC offset (e.g. `+01:00` or
 
 Consider the following example:
 
-[source,js]
+[source,console]
 ---------------------------------
 PUT my_index/log/1?refresh
 {
@@ -148,7 +146,6 @@ GET my_index/_search?size=0
   }
 }
 ---------------------------------
-// CONSOLE
 
 UTC is used if no time zone is specified, three 1-hour buckets are returned 
 starting at midnight UTC on 1 October 2015:
@@ -186,7 +183,7 @@ starting at midnight UTC on 1 October 2015:
 If a `time_zone` of `-01:00` is specified, then midnight starts at one hour before
 midnight UTC:
 
-[source,js]
+[source,console]
 ---------------------------------
 GET my_index/_search?size=0
 {
@@ -201,7 +198,6 @@ GET my_index/_search?size=0
   }
 }
 ---------------------------------
-// CONSOLE
 // TEST[continued]
 
 
@@ -273,7 +269,7 @@ The accepted units for `minimum_interval` are:
 * minute
 * second
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /sales/_search?size=0
 {
@@ -288,7 +284,6 @@ POST /sales/_search?size=0
     }
 }
 --------------------------------------------------
-// CONSOLE
 // TEST[setup:sales]
 
 ==== Missing value
@@ -297,7 +292,7 @@ The `missing` parameter defines how documents that are missing a value should be
 By default they will be ignored but it is also possible to treat them as if they
 had a value.
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /sales/_search?size=0
 {
@@ -312,7 +307,6 @@ POST /sales/_search?size=0
     }
 }
 --------------------------------------------------
-// CONSOLE
 // TEST[setup:sales]
 
 <1> Documents without a value in the `publish_date` field will fall into the same bucket as documents that have the value `2000-01-01`.

docs/reference/aggregations/bucket/children-aggregation.asciidoc

@@ -9,7 +9,7 @@ This aggregation has a single option:
 
 For example, let's say we have an index of questions and answers. The answer type has the following `join` field in the mapping:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 PUT child_example
 {
@@ -25,15 +25,14 @@ PUT child_example
   }
 }
 --------------------------------------------------
-// CONSOLE
 
 The `question` document contain a tag field and the `answer` documents contain an owner field. With the `children`
 aggregation the tag buckets can be mapped to the owner buckets in a single request even though the two fields exist in
 two different kinds of documents.
 
 An example of a question document:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 PUT child_example/_doc/1
 {
@@ -49,12 +48,11 @@ PUT child_example/_doc/1
   ]
 }
 --------------------------------------------------
-// CONSOLE
 // TEST[continued]
 
 Examples of `answer` documents:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 PUT child_example/_doc/2?routing=1
 {
@@ -86,12 +84,11 @@ PUT child_example/_doc/3?routing=1&refresh
   "creation_date": "2009-05-05T13:45:37.030"
 }
 --------------------------------------------------
-// CONSOLE
 // TEST[continued]
 
 The following request can be built that connects the two together:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST child_example/_search?size=0
 {
@@ -120,7 +117,6 @@ POST child_example/_search?size=0
   }
 }
 --------------------------------------------------
-// CONSOLE
 // TEST[continued]
 
 <1> The `type` points to type / mapping with the name `answer`.