Avoid BytesRef's copying in ScriptDocValues's Strings

[jimczi]

This commit refactors ScriptDocValues.Strings to directly creates String objects
instead of using an intermediate BytesRef's copy.
ScriptDocValues.Binary is also changed to create a single copy of BytesRef per consumed value.

Relates #29567

[elasticmachine]

Pinging @elastic/es-search-aggs

[jpountz]

We might want to benchmark this change. It does indeed remove one memcpy, but it also makes the String object allocation impossible to skip with escape analysis. I don't know whether escape analysis did succeed to skip the object allocation before, but if it did then this change would introduce a number of object allocations that is linear with the number of matches in the index?

Should we also look into making the utf8 conversion lazy so that scripts that only get the string value based on some other condition only pay the price for the utf8 conversion when the string is actually used?

[jimczi]

Should we also look into making the utf8 conversion lazy so that scripts that only get the string value based on some other condition only pay the price for the utf8 conversion when the string is actually used?

That sounds like the solution we have today and maybe a good reason to not proceed with this pr ?

[jpountz]

This specific issue might be fixable differently, eg. by reading doc values lazily, only if at least one value is requested?

[jimczi]

I pushed a commit to copy the values lazily, there's an IOException converted into an UncheckedIOException to make it work but as Adrien said if there is an exception here it's not good anyway. I'll see how I can benchmark this change now.

[colings86]

@jimczi was there any result from benchmarking yet? Is this still something we would like to get merged?

[jimczi]

I don't have time to work on this currently so I am closing this pr and will revisit later.