UpdateByQueryRequest fails with slices set to 0

[alainbodiguel]

Describe the feature:

Elasticsearch version (bin/elasticsearch --version): 7.6.0

Plugins installed: []

JVM version (java -version): 8

OS version (uname -a if on a Unix-like system):

Description of the problem including expected versus actual behavior:
With the JAVA High Level REST client, executing an UpdateByQueryRequest with a slice value of '0' results in an error: "[slices] must be a positive integer or the string "auto", but was [0]".

Obvioulsy as the setSlices() method expects an integer, we can't set the auto value.

Steps to reproduce:

        UpdateByQueryRequest request = new UpdateByQueryRequest("myindex")
                .setQuery(this.getBoolQueryBuilder())
                .setSlices(0)
                .setScript(myscript);
        BulkByScrollResponse response = esClient.updateByQuery(request, RequestOptions.DEFAULT);

Provide logs (if relevant):

Suppressed: org.elasticsearch.client.ResponseException: method [POST], host [http://elasticsearch:9200], URI [/dataset/_update_by_query?slices=0&requests_per_second=-1&ignore_unavailable=false&expand_wildcards=open&allow_no_indices=true&ignore_throttled=true&max_docs=2147483647&timeout=1m], status line [HTTP/1.1 400 Bad Request]
{"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"[slices] must be a positive integer or the string \"auto\", but was [0]"}],"type":"illegal_argument_exception","reason":"[slices] must be a positive integer or the string \"auto\", but was [0]"},"status":400}
		at org.elasticsearch.client.RestClient.convertResponse(RestClient.java:283)
		at org.elasticsearch.client.RestClient.performRequest(RestClient.java:261)
		at org.elasticsearch.client.RestClient.performRequest(RestClient.java:235)
		at org.elasticsearch.client.RestHighLevelClient.internalPerformRequest(RestHighLevelClient.java:1514)

[elasticmachine]

Pinging @elastic/es-core-features (:Core/Features/Java High Level REST Client)

[cbuescher]

@alainbodiguel thanks for opening this issue, I think this is the same as #53044 which should be fixed by #53068 in 7.6.2 coming out as the next patch release. I'll close this issue for that reason. Please reopen if the same behaviour still happens on a 7.6.2 client/server combination.

[cbuescher]

Closing as a duplicate of #53044