[DOCS] EQL: Remove collapsible sections from EQL search docs (#59819)

docs/reference/eql/search.asciidoc

@@ -11,9 +11,6 @@ search API>> to search event data stored in one or more {es} data streams or
 indices. The API requires a query written in {es}'s supported <<eql-syntax,EQL
 syntax>>.
 
-.*Example*
-[%collapsible]
-====
 To get started, ingest or add the data to an {es} data stream or index.
 
 The following <<docs-bulk,bulk API>> request adds some example log data to the
@@ -132,7 +129,6 @@ https://en.wikipedia.org/wiki/Unix_time[Unix epoch], in ascending order.
 // TESTRESPONSE[s/"took": 60/"took": $body.took/]
 // TESTRESPONSE[s/"_id": "OQmfCaduce8zoHT93o4H"/"_id": $body.hits.events.0._id/]
 // TESTRESPONSE[s/"_id": "xLkCaj4EujzdNSxfYLbO"/"_id": $body.hits.events.1._id/]
-====
 
 [discrete]
 [[eql-search-sequence]]
@@ -141,9 +137,6 @@ https://en.wikipedia.org/wiki/Unix_time[Unix epoch], in ascending order.
 Many query languages allow you to match single events. However, EQL's
 <<eql-sequences,sequence syntax>> lets you match an ordered series of events.
 
-.*Example*
-[%collapsible]
-====
 The following EQL search request matches a sequence that:
 
 . Starts with an event with:
@@ -410,7 +403,6 @@ GET /sec_logs/_eql/search
   """
 }
 ----
-====
 
 [discrete]
 [[eql-search-specify-event-category-field]]
@@ -420,9 +412,6 @@ By default, the EQL search API uses `event.category` as the
 <<eql-required-fields,event category field>>. You can use the
 `event_category_field` parameter to specify another event category field.
 
-.*Example*
-[%collapsible]
-====
 The following request specifies `file.type` as the event category
 field.
 
@@ -436,7 +425,6 @@ GET /sec_logs/_eql/search
   """
 }
 ----
-====
 
 [discrete]
 [[eql-search-specify-timestamp-field]]
@@ -446,9 +434,6 @@ By default, EQL searches use `@timestamp` as the <<eql-required-fields,event
 timestamp field>>. You can use the EQL search API's `timestamp_field` parameter
 to specify another timestamp field.
 
-.*Example*
-[%collapsible]
-====
 The following request specifies `file.accessed` as the event
 timestamp field.
 
@@ -462,7 +447,6 @@ GET /sec_logs/_eql/search
   """
 }
 ----
-====
 
 [discrete]
 [[eql-search-specify-a-sort-tiebreaker]]
@@ -475,9 +459,6 @@ field is used to sort the events in ascending, lexicographic order.
 The EQL search API uses `event.sequence` as the default tiebreaker field. You
 can use the `tiebreaker_field` parameter to specify another field.
 
-.*Example*
-[%collapsible]
-====
 The following request specifies `event.start` as the tiebreaker field.
 
 [source,console]
@@ -554,7 +535,6 @@ The API returns the following response.
 // TESTRESPONSE[s/"took": 34/"took": $body.took/]
 // TESTRESPONSE[s/"_id": "OQmfCaduce8zoHT93o4H"/"_id": $body.hits.events.0._id/]
 // TESTRESPONSE[s/"_id": "xLkCaj4EujzdNSxfYLbO"/"_id": $body.hits.events.1._id/]
-====
 
 
 [discrete]
@@ -565,9 +545,6 @@ You can use the EQL search API's `filter` parameter to specify an additional
 query using <<query-dsl,query DSL>>. This query filters the documents on which
 the EQL query runs.
 
-.*Example*
-[%collapsible]
-====
 The following request uses a `range` query to filter the `sec_logs`
 index down to only documents with a `file.size` value greater than `1` but less
 than `1000000` bytes. The EQL query in `query` parameter then runs on these
@@ -590,7 +567,6 @@ GET /sec_logs/_eql/search
   """
 }
 ----
-====
 
 [discrete]
 [[eql-search-async]]
@@ -625,9 +601,6 @@ API returns a response that includes:
 The async search continues to run in the background without blocking
 other requests.
 
-[%collapsible]
-.*Example*
-====
 The following request searches the `frozen_sec_logs` index, which has been
 <<frozen-indices,frozen>> for storage and is rarely searched.
 
@@ -670,7 +643,6 @@ search.
 // TESTRESPONSE[s/"is_running": true/"is_running": $body.is_running/]
 // TESTRESPONSE[s/"took": 2000/"took": $body.took/]
 // TESTRESPONSE[s/"hits": \.\.\./"hits": $body.hits/]
-====
 
 You can use the the returned search ID and the <<get-async-eql-search-api,get
 async EQL search API>> to check the progress of an ongoing async search.
@@ -681,9 +653,6 @@ like to wait for complete search results. If the request does not complete
 during this period, the response returns an `is_partial` value of `true` and no
 search results.
 
-[%collapsible]
-.*Example*
-====
 The following get async EQL search API request checks the progress of the
 previous async EQL search. The request specifies a `wait_for_completion_timeout`
 query parameter value of `2s` (two seconds).
@@ -713,7 +682,6 @@ finished and the search results in the `hits` property are complete.
 // TESTRESPONSE[s/"took": 2000/"took": $body.took/]
 // TESTRESPONSE[s/"_index": "frozen_sec_logs"/"_index": "sec_logs"/]
 // TESTRESPONSE[s/"hits": \.\.\./"hits": $body.hits/]
-====
 
 [discrete]
 [[eql-search-store-async-eql-search]]
@@ -725,9 +693,6 @@ five days. After this period, any ongoing searches or saved results are deleted.
 You can use the EQL search API's `keep_alive` parameter to change the duration
 of this period.
 
-.*Example*
-[%collapsible]
-====
 In the following EQL search API request, the `keep_alive` parameter is `2d` (two
 days). This means that if the search becomes async, its results
 are stored on the cluster for two days. After two days, the async
@@ -744,15 +709,11 @@ GET /sec_logs/_eql/search
   """
 }
 ----
-====
 
 You can use the <<get-async-eql-search-api,get async EQL search API>>'s
 `keep_alive` query parameter to later change the retention period. The new
 retention period starts after the get async EQL search API request executes.
 
-.*Example*
-[%collapsible]
-====
 The following get async EQL search API request sets the `keep_alive` query
 parameter to `5d` (five days). The async search and its results are deleted five
 days after the get async EQL search API request executes.
@@ -762,15 +723,11 @@ days after the get async EQL search API request executes.
 GET /_eql/search/FmNJRUZ1YWZCU3dHY1BIOUhaenVSRkEaaXFlZ3h4c1RTWFNocDdnY2FSaERnUTozNDE=?keep_alive=5d
 ----
 // TEST[skip: no access to search ID]
-====
 
 You can use the <<delete-async-eql-search-api,delete async EQL search API>> to
 manually delete an async EQL search before the `keep_alive` period ends. If the
 search is still ongoing, this cancels the search request.
 
-.*Example*
-[%collapsible]
-====
 The following delete async EQL search API request deletes an async EQL search
 and its results.
 
@@ -779,7 +736,6 @@ and its results.
 DELETE /_eql/search/FmNJRUZ1YWZCU3dHY1BIOUhaenVSRkEaaXFlZ3h4c1RTWFNocDdnY2FSaERnUTozNDE=?keep_alive=5d
 ----
 // TEST[skip: no access to search ID]
-====
 
 [discrete]
 [[eql-search-store-sync-eql-search]]
@@ -791,9 +747,6 @@ completed within the period set by the `wait_for_completion_timeout` parameter.
 To save the results of searches that complete during this period, set the
 `keep_on_completion` parameter to `true`.
 
-[%collapsible]
-.*Example*
-====
 In the following EQL search API request, the `keep_on_completion` parameter is
 `true`. This means the search results are stored on the cluster, even if
 the search completes within the `2s` (two-second) period set by the
@@ -838,7 +791,6 @@ search API>> to retrieve the same results later.
 GET /_eql/search/FjlmbndxNmJjU0RPdExBTGg0elNOOEEaQk9xSjJBQzBRMldZa1VVQ2pPa01YUToxMDY=
 ----
 // TEST[skip: no access to search ID]
-====
 
 Saved synchronous searches are still subject to the storage retention period set
 by the `keep_alive` parameter. After this period, the search and its saved
@@ -854,9 +806,6 @@ You can also manually delete saved synchronous searches using the
 By default, matching for EQL queries is case-insensitive. You can use the EQL
 search API's `case_sensitive` parameter to toggle case sensitivity on or off.
 
-.*Example*
-[%collapsible]
-====
 The following search request contains a query that matches `process` events
 with a `process.executable` containing `System32`.
 
@@ -876,4 +825,3 @@ GET /sec_logs/_eql/search
   """
 }
 ----
-====