[codegen] update to latest spec

Author: l-trotta

java-client/src/main/java/co/elastic/clients/elasticsearch/ElasticsearchAsyncClient.java

@@ -4826,17 +4826,16 @@ public final <TDocument> CompletableFuture<ScrollResponse<TDocument>> scroll(
 	 * When paging through a large number of documents, it can be helpful to split
 	 * the search into multiple slices to consume them independently with the
 	 * <code>slice</code> and <code>pit</code> properties. By default the splitting
-	 * is done first on the shards, then locally on each shard. The local splitting
-	 * partitions the shard into contiguous ranges based on Lucene document IDs.
+	 * is done first on the shards, then locally on each shard.
 	 * <p>
 	 * For instance if the number of shards is equal to 2 and you request 4 slices,
 	 * the slices 0 and 2 are assigned to the first shard and the slices 1 and 3 are
 	 * assigned to the second shard.
 	 * <p>
 	 * IMPORTANT: The same point-in-time ID should be used for all slices. If
 	 * different PIT IDs are used, slices can overlap and miss documents. This
-	 * situation can occur because the splitting criterion is based on Lucene
-	 * document IDs, which are not stable across changes to the index.
+	 * situation can occur because, by default, the splitting criterion is based on
+	 * Lucene document IDs, which are not stable across changes to the index.
 	 * 
 	 * @see <a href=
 	 *      "https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-search">Documentation
@@ -4871,17 +4870,16 @@ public <TDocument> CompletableFuture<SearchResponse<TDocument>> search(SearchReq
 	 * When paging through a large number of documents, it can be helpful to split
 	 * the search into multiple slices to consume them independently with the
 	 * <code>slice</code> and <code>pit</code> properties. By default the splitting
-	 * is done first on the shards, then locally on each shard. The local splitting
-	 * partitions the shard into contiguous ranges based on Lucene document IDs.
+	 * is done first on the shards, then locally on each shard.
 	 * <p>
 	 * For instance if the number of shards is equal to 2 and you request 4 slices,
 	 * the slices 0 and 2 are assigned to the first shard and the slices 1 and 3 are
 	 * assigned to the second shard.
 	 * <p>
 	 * IMPORTANT: The same point-in-time ID should be used for all slices. If
 	 * different PIT IDs are used, slices can overlap and miss documents. This
-	 * situation can occur because the splitting criterion is based on Lucene
-	 * document IDs, which are not stable across changes to the index.
+	 * situation can occur because, by default, the splitting criterion is based on
+	 * Lucene document IDs, which are not stable across changes to the index.
 	 * 
 	 * @param fn
 	 *            a function that initializes a builder to create the
@@ -4935,17 +4933,16 @@ public final CompletableFuture<SearchResponse<Void>> search(
 	 * When paging through a large number of documents, it can be helpful to split
 	 * the search into multiple slices to consume them independently with the
 	 * <code>slice</code> and <code>pit</code> properties. By default the splitting
-	 * is done first on the shards, then locally on each shard. The local splitting
-	 * partitions the shard into contiguous ranges based on Lucene document IDs.
+	 * is done first on the shards, then locally on each shard.
 	 * <p>
 	 * For instance if the number of shards is equal to 2 and you request 4 slices,
 	 * the slices 0 and 2 are assigned to the first shard and the slices 1 and 3 are
 	 * assigned to the second shard.
 	 * <p>
 	 * IMPORTANT: The same point-in-time ID should be used for all slices. If
 	 * different PIT IDs are used, slices can overlap and miss documents. This
-	 * situation can occur because the splitting criterion is based on Lucene
-	 * document IDs, which are not stable across changes to the index.
+	 * situation can occur because, by default, the splitting criterion is based on
+	 * Lucene document IDs, which are not stable across changes to the index.
 	 * 
 	 * @see <a href=
 	 *      "https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-search">Documentation
@@ -4979,17 +4976,16 @@ public <TDocument> CompletableFuture<SearchResponse<TDocument>> search(SearchReq
 	 * When paging through a large number of documents, it can be helpful to split
 	 * the search into multiple slices to consume them independently with the
 	 * <code>slice</code> and <code>pit</code> properties. By default the splitting
-	 * is done first on the shards, then locally on each shard. The local splitting
-	 * partitions the shard into contiguous ranges based on Lucene document IDs.
+	 * is done first on the shards, then locally on each shard.
 	 * <p>
 	 * For instance if the number of shards is equal to 2 and you request 4 slices,
 	 * the slices 0 and 2 are assigned to the first shard and the slices 1 and 3 are
 	 * assigned to the second shard.
 	 * <p>
 	 * IMPORTANT: The same point-in-time ID should be used for all slices. If
 	 * different PIT IDs are used, slices can overlap and miss documents. This
-	 * situation can occur because the splitting criterion is based on Lucene
-	 * document IDs, which are not stable across changes to the index.
+	 * situation can occur because, by default, the splitting criterion is based on
+	 * Lucene document IDs, which are not stable across changes to the index.
 	 * 
 	 * @param fn
 	 *            a function that initializes a builder to create the

java-client/src/main/java/co/elastic/clients/elasticsearch/ElasticsearchClient.java

@@ -4864,17 +4864,16 @@ public final <TDocument> ScrollResponse<TDocument> scroll(
 	 * When paging through a large number of documents, it can be helpful to split
 	 * the search into multiple slices to consume them independently with the
 	 * <code>slice</code> and <code>pit</code> properties. By default the splitting
-	 * is done first on the shards, then locally on each shard. The local splitting
-	 * partitions the shard into contiguous ranges based on Lucene document IDs.
+	 * is done first on the shards, then locally on each shard.
 	 * <p>
 	 * For instance if the number of shards is equal to 2 and you request 4 slices,
 	 * the slices 0 and 2 are assigned to the first shard and the slices 1 and 3 are
 	 * assigned to the second shard.
 	 * <p>
 	 * IMPORTANT: The same point-in-time ID should be used for all slices. If
 	 * different PIT IDs are used, slices can overlap and miss documents. This
-	 * situation can occur because the splitting criterion is based on Lucene
-	 * document IDs, which are not stable across changes to the index.
+	 * situation can occur because, by default, the splitting criterion is based on
+	 * Lucene document IDs, which are not stable across changes to the index.
 	 * 
 	 * @see <a href=
 	 *      "https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-search">Documentation
@@ -4909,17 +4908,16 @@ public <TDocument> SearchResponse<TDocument> search(SearchRequest request, Class
 	 * When paging through a large number of documents, it can be helpful to split
 	 * the search into multiple slices to consume them independently with the
 	 * <code>slice</code> and <code>pit</code> properties. By default the splitting
-	 * is done first on the shards, then locally on each shard. The local splitting
-	 * partitions the shard into contiguous ranges based on Lucene document IDs.
+	 * is done first on the shards, then locally on each shard.
 	 * <p>
 	 * For instance if the number of shards is equal to 2 and you request 4 slices,
 	 * the slices 0 and 2 are assigned to the first shard and the slices 1 and 3 are
 	 * assigned to the second shard.
 	 * <p>
 	 * IMPORTANT: The same point-in-time ID should be used for all slices. If
 	 * different PIT IDs are used, slices can overlap and miss documents. This
-	 * situation can occur because the splitting criterion is based on Lucene
-	 * document IDs, which are not stable across changes to the index.
+	 * situation can occur because, by default, the splitting criterion is based on
+	 * Lucene document IDs, which are not stable across changes to the index.
 	 * 
 	 * @param fn
 	 *            a function that initializes a builder to create the
@@ -4974,17 +4972,16 @@ public final SearchResponse<Void> search(Function<SearchRequest.Builder, ObjectB
 	 * When paging through a large number of documents, it can be helpful to split
 	 * the search into multiple slices to consume them independently with the
 	 * <code>slice</code> and <code>pit</code> properties. By default the splitting
-	 * is done first on the shards, then locally on each shard. The local splitting
-	 * partitions the shard into contiguous ranges based on Lucene document IDs.
+	 * is done first on the shards, then locally on each shard.
 	 * <p>
 	 * For instance if the number of shards is equal to 2 and you request 4 slices,
 	 * the slices 0 and 2 are assigned to the first shard and the slices 1 and 3 are
 	 * assigned to the second shard.
 	 * <p>
 	 * IMPORTANT: The same point-in-time ID should be used for all slices. If
 	 * different PIT IDs are used, slices can overlap and miss documents. This
-	 * situation can occur because the splitting criterion is based on Lucene
-	 * document IDs, which are not stable across changes to the index.
+	 * situation can occur because, by default, the splitting criterion is based on
+	 * Lucene document IDs, which are not stable across changes to the index.
 	 * 
 	 * @see <a href=
 	 *      "https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-search">Documentation
@@ -5019,17 +5016,16 @@ public <TDocument> SearchResponse<TDocument> search(SearchRequest request, Type
 	 * When paging through a large number of documents, it can be helpful to split
 	 * the search into multiple slices to consume them independently with the
 	 * <code>slice</code> and <code>pit</code> properties. By default the splitting
-	 * is done first on the shards, then locally on each shard. The local splitting
-	 * partitions the shard into contiguous ranges based on Lucene document IDs.
+	 * is done first on the shards, then locally on each shard.
 	 * <p>
 	 * For instance if the number of shards is equal to 2 and you request 4 slices,
 	 * the slices 0 and 2 are assigned to the first shard and the slices 1 and 3 are
 	 * assigned to the second shard.
 	 * <p>
 	 * IMPORTANT: The same point-in-time ID should be used for all slices. If
 	 * different PIT IDs are used, slices can overlap and miss documents. This
-	 * situation can occur because the splitting criterion is based on Lucene
-	 * document IDs, which are not stable across changes to the index.
+	 * situation can occur because, by default, the splitting criterion is based on
+	 * Lucene document IDs, which are not stable across changes to the index.
 	 * 
 	 * @param fn
 	 *            a function that initializes a builder to create the