[3.x] Address slow copy performance when using the FileAccessFilesystemJAndroid implementation

[m4gr3d]

Read/write ops for this implementation are done through the java layer via jni, and so for good performance, it's key to avoid numerous repeated small read/write ops due the jni overhead.

The alternative is to allocate a (conversatively-sized) large buffer to reduce the number of read/write ops over the jni boundary.

Fixes #62969

3.x version of #63242

[lawnjelly]

Might be a little more "Godotey" to use a LocalVector local variable for this rather than alloc the buffer directly, but that's more a style / maintenance nitpick, using a buffer directly isn't any worse.

An alternative could be to persist the vector to prevent multiple allocations, but probably won't make a massive difference as file access is expected to be slow anyway, and the approach in the PR avoids tying up any memory.

Also might be a tad better practice to just have the COPY_BUFFER_LIMIT a local const unless it was used in multiple places, to avoid polluting global namespace.

These are all nitpicks though, up to you if you wanted to change imo.

P.S. Haven't tried running it, only looking at the function.

EDIT: Noticed one possible bug though. get_buffer() can return -1 in error condition (maybe this doesn't happen in practice) but might be good to check for this, get_buffer() could change in future. This can probably only currently happen if the malloc fails but could be worth checking that too and ERR_FAILing?

[akien-mga]

Thanks!