Create an array-based version of ChunkedToXContentBuilder

[thecoop]

Use fixed-size arrays, but the methods and semantics of ChunkedToXContentBuilder

Fixes #118647

[original-brownbear]

I'm sorry @thecoop but I fail to see what this is trying to achieve.
Yes this is probably somewhat faster than the previous version but also obviously slower than the original version without the builder. Again, the chunked x-content logic is only applicable to a very narrow set of use-cases and any API that makes it look nicer (somewhat subjective to begin with, but I get where this is coming from) by adding more push-style logic before the pull-style iteration will slow things down.
Is it really worth all this noise and cost iterating on a builder implementation when the previous implementation will always be faster and really since this is transport thread logic and about as hot as anything ever gets in ES, that is all that matters pretty much. If anything, I'd rather look into writing custom code for search response and bulk response instead of chaining iterators since both of these are considerable CPU consumers.
Sorry but looking at benchmarks and profiling in general we want faster here and any abstraction layer means slower (and slower means less stable because we're on transport threads!).
=> in light of the cost of all of this, is there any reason to not just revert to the old version and be done with this? :)

[thecoop]

Can you point to how this will be slower? The objects returned are the same types returned by the previous ChunkedToXContentHelper methods.

[original-brownbear]

This one in isolation isn't much slower but even this still has the negative effect of duplicating existing implementations in ChunkedToXContentHelper (and reintroduction of a method previously deleted from that) which is just needless overhead as well (larger table to look up from for the virtual calls).
My point here really was just: we had something that worked reasonably fast why not just go back to that and be happy with it and optimize further rather than go through all this noise? :) Also, note that we started from issues with slow search response serialization, this doesn't remove the slow builder nor addresses search responses in any way?
A fix for #118647 should deal with the slow builder, not just (re-)add duplicate code for one specific path?

[thecoop]

This is a WIP - the code here is an example of the changes I would like to make. I am continuing to refactor the old builder to the new one now.

I want to do this change because it makes the code easier to understand and less error-prone, especially given the obtuseness of some exceptions when you mis-match start and end blocks. The methods here are designed to minimise the chances of doing that by doing the start and end for you, in the same style as ChunkedToXContentBuilder (as I encountered when doing some changes in elasticsearch-internal).

I also did these changes as there was little documentation or comments specifying the performance-critical nature of this code. May I suggest adding assertions for specific types, and extensive comments explaining what is going on, if these are necessary to ensure certain calls do not turn megamorphic?