mobile: Use direct ByteBuffer to pass data between C++ and Java

[fredyw]

This PR updates the JNI code to use direct ByteBuffer to pass the data between C++ and Java. This change helps to reduce the number of copying needed, especially between jbyteArray (C++) and byte[] (Java). The direct ByteBuffer is backed by envoy_data without any copy.

Before:

1. Buffer:Instance is created by Envoy.
2. Create envoy_data from Buffer::Instance by copying.
3. Create jbyteArray from envoy_data by copying.
4. Pass the jbyteArray (C++) to byte[] (Java). This typically involves a copy, but it's implementation dependent.
5. Wrap the byte[] into ByteBuffer (no copy, memory managed by the JVM).

After:

1. Buffer:Instance is created by Envoy.
2. Create envoy_data from Buffer::Instance by copying.
3. Wraps the envoy_data into direct ByteBuffer (no copy).
4. Pass the ByteBuffer directly from C++ to Java (no copy).
5. Create a copy of the ByteBuffer in the callbacks for further use. This is needed because the direct ByteBuffer backed by envoy_data will be destroyed upon completing the callback. Technically, we could let the user-defined callback create a copy as needed, such as if it needs the data to outlive the callback lifetime. However, doing that would put a burden on the users whether or not a copy is needed and failing to do so could result in garbage data. To make things less error-prone, all data passed into the user-defined callbacks will be a copy.

Reference: https://developer.android.com/training/articles/perf-jni#faq:-how-do-i-share-raw-data-with-native-code

Risk Level: medium
Testing: unit tests
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: mobile

[repokitteh-read-only]

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #32715 was opened by fredyw.

see: more, trace.

[fredyw]

/assign @abeyad

[fredyw]

/retest

[abeyad]

Nice, thanks @fredyw ! The PR description was super helpful too.

Question from that though, you mentioned:

Create a copy of the ByteBuffer in the callbacks for further use. 

So from what I understood, if we actually use the data in a callback (which is the majority case?), then both before and after will result in 2 copies of the data. Is this correct?

[fredyw]

Nice, thanks @fredyw ! The PR description was super helpful too.

Question from that though, you mentioned:

Create a copy of the ByteBuffer in the callbacks for further use. 

So from what I understood, if we actually use the data in a callback (which is the majority case?), then both before and after will result in 2 copies of the data. Is this correct?

Yes, that's correct. The only thing that this PR will save is between the jByteArray to byte[]. There's another thing that I'm experimenting to reduce the number of copies to just 1, but this is going to be a slightly breaking change and I plan to work on it in the next PR.

[abeyad]

Sorry, I had missed step #4 in your "Before" description, which usually involves a copy, so before is 3 copies, and after is 2 copies. Awesome!