Default reindex to return first 50 bulk failures

[nik9000]

Reindex, update_by_query, and delete_by_query work in batches based
on the scroll size of their source query, defaulting to 1000 documents
at a time. If all 1000 of those documents fail this returns an
avalanche of errors which is just fine over the Java API and, probably,
fine for any programatic consumers over the REST API as well. But for
interactive users the size of the response can be devestating.

So this commit creates a URL parameter to control the number of
indexing failures returned in the response,
max_reported_bulk_failures, which defaults to 50. The option
also exists in the Transport Client for completeness sake but
defaults to Integer.MAX_VALUE because transport client users are
unlikely to suffer if the response is large. Even though the
default is Integer.MAX_VALUE, not more than batch_size errors
are ever returned because a single error causes reindex to abort
after processing the current batch.

Closes #20199

[clintongormley]

I don't think we need an override setting here. Reindex aborts when it gets error messages, and there is no indication of how many more exceptions would be thrown if reindex had just continued. I can't imagine a use case where a user will programmatically process each error case.

[nik9000]

I can't imagine a use case where a user will programmatically process each error case.

I'm thinking mostly of shops where it takes a long time to push new code. If it takes two weeks to push a new reindex you really want all the error messages you can get. I suppose they could get them from the log though.