Split reindex and update by query failures exposed on the REST interface

[Mpdreamz]

Right now we expose BulkItemResponse.Failure and ShardSearchFailures under a single failures property but these classes are of different shapes.

e.g one of the failures writes the throwable as cause the other as reason.

It would be nice if we can expose them under index_failures and search_failures, the way they are stored on the BulkIndexByScrollResponse.

Or come up with a single BulkIndexByScrollResponse.Failure

I am wondering what the development guidelines/best practices are for exposing failures? We have quite a few Failure inner classes that do not relate to one another?

cc @nik9000

[nik9000]

I think we'd be better off standardizing on things like cause and reason. Then indexing failure would look "just like" a search failure with some extra data about the indexing operation that failed.

[elasticmachine]

Pinging @elastic/es-distributed

[elasticsearchmachine]

Pinging @elastic/es-distributed (Team:Distributed)