Turn this into a chunked response to some degree.
Only chunks per node for now, since deeper chunking needs larger changes downstream that don't fit in well with the current API.
The problem is that the "level" parameter that controls whether or not we return the very large indices or shard level responses is an x-content param so we don't have it when creating the iterator. I'd address this in a follow-up that changes the API a little.

As a result, I did not add a test here that validates the chunk count since I'd like to do more work on this anyway. I think it's a valuable change in its current form already and introduces a parent class that allows for turning other APIs into chunked encoding also.
For example, the indices level response for node stats in a 25k indices cluster across 6 data nodes is currently ~120M (and that is without pretty or human!). Without this change, each hit of the indices stats API will cause the coordinating node to allocate 120M for the response. With this change, we will only allocate ~20M for sending the same response. Serializing those 20M on the transport thread should be a non-issue from some quick benchmarking as even serializing the full 120M seems to well under one second.

relates #89838