Allow specifying index names in request body

[jloleysens]

Many ES APIs currently provide a way to query for a set of indices by specifying comma separated index patterns. In certain scenarios, scripted querying of these endpoints can create very long URIs (+4096 bytes) that trigger an ES exception (elastic/kibana#72616, https://discuss.elastic.co/t/url-too-long-too-many-indices/143593/4) or could run into a web server's URI length limit in certain configurations (although these are typically longer).

This is constrained to scenarios where:

1. You want a very specific subset of indices on the fly (aliases, index patterns or data streams probably cannot help)
2. The subset are many such that the names CSV'd (probably URI encoded too) are more than 4096 bytes
3. You are probably interacting with ES in scripted programmatic way to achieve specific functionality (i.e., this is a latent issue that will be triggered once the number of indices has grown large)

It seems the index names would need to passed through in some other way (perhaps a PUT or GET with a body?) or creating and deleting aliases on the fly although I am not sure that would have been viable in a case like elastic/kibana#72616, but fortunately the new resolve endpoint could be used to get the information that was needed.

Is there a general way of setting things up so that this limit will not be hit given the current APIs?

[DaveCTurner]

#52367 is a more specific instance of this. Today the answer is no, but being able to specify a longer list of indices in a channel other than the URI (maybe the request body) seems like a reasonable thing to want IMO.

[elasticmachine]

Pinging @elastic/es-core-infra (:Core/Infra/REST API)

[pugnascotia]

ES could also be behind a proxy that also restricts URI length, so again it would be useful to have another option for specifying indices.

[pugnascotia]

We talked about this in the Core/Infra sync. We felt that it is reasonable to be able to specify the list of indices in the request body as well as the URL. The next step here would be to work out the scope and impact of the required changes, since we'd need to update the REST API in a number of places.

[rjernst]

As noted above, we don't object to such a change, but this is also an edge case that most users don't come anywhere near to hitting. So I have marked this as an adoptme. Please feel free to open a PR.

[i-plusplus]

@rjernst @pugnascotia Can I take it up ?