Docs: Document failures on reindex and friends

We already had *some* documentation of the batch nature of `reindex` and
friends but it wasn't super obvious how it interacted with the
`failures` element in the response. This adds some more documentation
the `failures` element.

docs/reference/docs/delete-by-query.asciidoc

@@ -284,9 +284,12 @@ executed again in order to conform to `requests_per_second`.
 
 `failures`::
 
-Array of all indexing failures. If this is non-empty then the request aborted
-because of those failures. See `conflicts` for how to prevent version conflicts
-from aborting the operation.
+Array of failures if there were any unrecoverable errors during the process. If
+this is non-empty then the request aborted because of those failures.
+Delete-by-query is implemented using batches and any failure causes the entire
+process to abort but all failures in the current batch are collected into the
+array. You can use the `conflicts` option to prevent reindex from aborting on
+version conflicts.
 
 
 [float]

docs/reference/docs/reindex.asciidoc

@@ -161,12 +161,12 @@ POST _reindex
 
 `index` and `type` in `source` can both be lists, allowing you to copy from
 lots of sources in one request. This will copy documents from the `_doc` and
-`post` types in the `twitter` and `blog` index. The copied documents would include the 
-`post` type in the `twitter` index and the `_doc` type in the `blog` index. For more 
+`post` types in the `twitter` and `blog` index. The copied documents would include the
+`post` type in the `twitter` index and the `_doc` type in the `blog` index. For more
 specific parameters, you can use `query`.
 
-The Reindex API makes no effort to handle ID collisions. For such issues, the target index 
-will remain valid, but it's not easy to predict which document will survive because 
+The Reindex API makes no effort to handle ID collisions. For such issues, the target index
+will remain valid, but it's not easy to predict which document will survive because
 the iteration order isn't well defined.
 
 [source,js]
@@ -666,9 +666,11 @@ executed again in order to conform to `requests_per_second`.
 
 `failures`::
 
-Array of all indexing failures. If this is non-empty then the request aborted
-because of those failures. See `conflicts` for how to prevent version conflicts
-from aborting the operation.
+Array of failures if there were any unrecoverable errors during the process. If
+this is non-empty then the request aborted because of those failures. Reindex
+is implemented using batches and any failure causes the entire process to abort
+but all failures in the current batch are collected into the array. You can use
+the `conflicts` option to prevent reindex from aborting on version conflicts.
 
 [float]
 [[docs-reindex-task-api]]
@@ -1004,7 +1006,7 @@ number for most indices. If slicing manually or otherwise tuning
 automatic slicing, use these guidelines.
 
 Query performance is most efficient when the number of `slices` is equal to the
-number of shards in the index. If that number is large (e.g. 500), 
+number of shards in the index. If that number is large (e.g. 500),
 choose a lower number as too many `slices` will hurt performance. Setting
 `slices` higher than the number of shards generally does not improve efficiency
 and adds overhead.
@@ -1018,7 +1020,7 @@ documents being reindexed and cluster resources.
 [float]
 === Reindex daily indices
 
-You can use `_reindex` in combination with <<modules-scripting-painless, Painless>> 
+You can use `_reindex` in combination with <<modules-scripting-painless, Painless>>
 to reindex daily indices to apply a new template to the existing documents.
 
 Assuming you have indices consisting of documents as follows:

docs/reference/docs/update-by-query.asciidoc

@@ -338,9 +338,13 @@ executed again in order to conform to `requests_per_second`.
 
 `failures`::
 
-Array of all indexing failures. If this is non-empty then the request aborted
-because of those failures. See `conflicts` for how to prevent version conflicts
-from aborting the operation.
+Array of failures if there were any unrecoverable errors during the process. If
+this is non-empty then the request aborted because of those failures.
+Update-by-query is implemented using batches and any failure causes the entire
+process to abort but all failures in the current batch are collected into the
+array. You can use the `conflicts` option to prevent reindex from aborting on
+version conflicts.
+
 
 
 [float]