Make ByteSourceJsonBootstrapper use StringReader for < 8KiB byte[] inputs

[schlosna]

From @carterkozak #1079 (comment) this is an alternative implementation draft to address #593 (and #995 (comment) ) when deserializing from a byte[] as the InputStreamReader code path triggers an 8KiB HeapByteBuffer allocation for StreamDecoder regardless of input byte array length. This allocation significantly penalizes smaller byte[] sources.

The approach here converts byte[] inputs smaller thank 8KiB to a String and processed via StringReader. This should avoid unnecessary 8KiB heap byte buffer allocation and leverage OpenJDK's continued charset decoding improvements (e.g. https://cl4es.github.io/2021/02/23/Faster-Charset-Decoding.html ).

Initial benchmarks from FasterXML/jackson-benchmarks#9 show StringReader providing performance equivalent to ByteArrayInputStream source in worst case, and anywhere from ~2x to ~10x speedup in best case.

[pjfanning]

minor nit: It may not be worth checking length >= 0. It has a small perf impact and the length is very unlikely to negative and will just fail at the ByteArrayInputStream stage anyway. The length == 0 case will probably be more tidily handled with the StringReader than the ByteArrayInputStream route.

[schlosna]

I flipped the condition to short circuit for large inputs first if (length <= STRING_READER_BYTE_ARRAY_LENGTH_LIMIT && length >= 0).

I'd prefer to keep the length >= 0 as the array length check here should be negligible, and ensures the ByteInputStream continues handling any negative array length path.

[schlosna]

After thinking it through over night, I removed the length >= 0 condition.

[cowtowncoder]

Ok I assume this has been benchmarked and since it only affects what I assume is minority use case (non-UTF-8 input that comes as byte input), I am ok merging it.
(but obviously is a use case that matters to some otherwise wouldn't be contributed :) ).

Thank you @schlosna !