[8.5] [docs] Update search-settings documentation to reflect the fact that the indices.query.bool.max_clause_count setting has been deprecated (#91811)

docs/reference/modules/indices/search-settings.asciidoc

@@ -6,23 +6,24 @@ limits.
 
 [[indices-query-bool-max-clause-count]]
 `indices.query.bool.max_clause_count`::
+deprecated:[8.0.0]
 (<<static-cluster-setting,Static>>, integer)
-Maximum number of clauses a query can contain. Defaults to `4096`.
+This deprecated setting has no effect.
 +
-This setting limits the total number of clauses that a query tree can have. The default of 4096
-is quite high and should normally be sufficient. This limit applies to the rewritten query, so
-not only `bool` queries can contribute high numbers of clauses, but also all queries that rewrite
-to `bool` queries internally such as `fuzzy` queries. The limit is in place to prevent searches
-from becoming too large, and taking up too much CPU and memory. In case you're considering
-increasing this setting, make sure you've exhausted all other options to avoid having to do this.
-Higher values can lead to performance degradations and memory issues, especially in clusters with
-a high load or few resources.
-
-Elasticsearch offers some tools to avoid running into issues with regards to the maximum number of
-clauses such as the <<query-dsl-terms-query,`terms`>> query, which allows querying many distinct
-values while still counting as a single clause, or the <<index-prefixes,`index_prefixes`>> option
-of <<text-field-type,`text`>> fields, which allows executing prefix queries that expand to a high
-number of terms as a single term query.
+{es} will now dynamically set the maximum number of allowed clauses in a query, using
+a heuristic based on the size of the search thread pool and the size of the heap allocated to
+the JVM. This limit has a minimum value of 1024 and will in most cases be larger (for example,
+a node with 30Gb RAM and 48 CPUs will have a maximum clause count of around 27,000). Larger
+heaps lead to higher values, and larger thread pools result in lower values.
++
+Queries with many clauses should be avoided whenever possible. If you previously bumped this
+setting to accommodate heavy queries, you might need to increase the amount of memory available
+to {es}, or to reduce the size of your search thread pool so that more memory is
+available to each concurrent search.
++
+In previous versions of Lucene you could get around this limit by nesting boolean queries
+within each other, but the limit is now based on the total number of leaf queries within the
+query as a whole and this workaround will no longer help.
 
 [[search-settings-max-buckets]]
 `search.max_buckets`::

docs/reference/release-notes/8.1.0.asciidoc

@@ -143,6 +143,9 @@ CRUD::
 Cluster Coordination::
 * Remove last few mentions of Zen discovery {es-pull}80410[#80410]
 
+Search::
+* Deprecate the `indices.query.bool.max_clause_count` node setting {es-pull}81525[#81525] (issue: {es-issue}46433[#46433])
+
 SQL::
 * Deprecate `index_include_frozen` request parameter {es-pull}83943[#83943] (issue: {es-issue}81939[#81939])