Share PyArrow table data with the server through ByteBuffer

[jmao-denver]

Fixes #4935
Fixes #3709

depends on jpy-consortium/jpy#112
depends on #5022

[devinrsmith]

So, I think we need to add a big warning here and link to jpy-consortium/jpy#126; no strong references to this buffer can exist by the end of this method. I think we need to extend this warning into the implementation of parseSchema as well - it can't hold any references to Schema header (since that has references to the byte buffer).

[devinrsmith]

Flatbuffer almost certainly retains references to ByteBuffer. We need to be very careful that nothing retains this flatbuffer object. I think we need to add a big warning in io.deephaven.extensions.barrage.util.ArrowToTableConverter#createBarrageMessage that nothing can retain reference to BarrageProtoUtil.MessageInfo mi

[devinrsmith]

I think we need to carefully audit all of the parsing logic here to make sure no ByteBuffer / Flatbuffer object is retained. It's not obvious to me without digging in further to the implementations, which is why trying to use jpy.byte_buffer as it exists today is so dangerous. I think @nbauernfeind to review with this context in mind and go down through the implementations to double check.

[chipkent]

OK with me if all of @devinrsmith 's suggestions have been addressed. My comments are optional.

[nbauernfeind]

I dug in a bit. All of the flatbuffer usages that could reference the byte buffer (such as for strings) perform copies. (In particular the internal flatbuffer __string method copies during decoding). The extractChunkFromInputStream implementations similarly will copy via new String(buf, offset, length) invocations. Similarly any arrays extract a copy from the contiguous body payload rather than an effective slice.

AFAICT this change looks safe.

[devinrsmith]

Please add warning comment inside of parseSchema and createBarrageMessage as well.