[GEODE-10646] Reduce up-front buffer allocation in the Lucene file output stream

[JinwooHwang]

Reduce up-front buffer allocation in the Lucene file output stream

For all changes, please confirm:

• Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?
• Has your PR been rebased against the latest commit within the target branch (typically develop)?
• Is your initial contribution a single, squashed commit?
• Does gradlew build run cleanly?
• Have you written or updated unit tests to verify your changes?
• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

[sboorlagadda]

The chunking behavior looks preserved, and the existing large-write test plus
the new round-trip test provide useful coverage. Before approving the memory
optimization, could you add a test that detects reintroducing the eager 1 MiB
allocation and share a base/head allocation or GC comparison for small and
larger outputs? A fresh stream reaching 1 MiB now allocates 2040 KiB of buffer
arrays and recopies 1016 KiB during growth, although it saves substantially for
small files. If this is intended to address the integration-test OOM, please
also link evidence connecting that failure to these buffers; the existing
ticket discusses ClassGraph and ByteBuffersDirectory, a separate storage path.

[JinwooHwang]

Thanks for the review, @sboorlagadda.

Added FileOutputStreamJUnitTest.testSmallFileAllocatesLessThanChunkSize, which measures thread allocation while writing a 100-byte file. It fails against develop's FileOutputStream (1,055,576 bytes allocated) and passes on this branch.

Base/head allocation per stream in bytes (JDK 17, ThreadMXBean, best of 7, 1000-byte writes, open through close):

Written     develop      GEODE-10646
1,000 B     1,055,896       15,480
64 KiB      1,120,432      194,920
512 KiB     1,579,184    1,571,392
1 MiB       2,103,472    3,144,328
5 MiB       6,322,864    7,363,784

This is consistent with your numbers: outputs reaching 1 MiB allocate about 1 MiB more per stream, from buffer growth.

This PR isn't intended to address the integration-test OOM.

To verify the effect with many streams open at once, I opened 452 streams on a map-backed FileSystem and wrote 2 KiB to each, using a 768 MiB heap. On develop each stream reserves a full 1 MiB buffer at open, and the 452 streams did not fit in the heap. On this branch the same streams retained about 6 MB.

[JinwooHwang]

The stream now buffers each chunk in 8 KiB segments that are allocated only when needed and reused for later chunks. Each chunk is copied once into an exactly sized array, so the buffer never grows by copying.

Allocation per stream in bytes (JDK 17, ThreadMXBean, best of 21 runs across 3 JVMs, 1000-byte writes, open through close):

Written	develop	GEODE-10646	Change
1,000 B	1,056,080	16,144	-98.47%
64 KiB	1,120,616	138,136	-87.67%
512 KiB	1,579,368	1,056,536	-33.10%
1 MiB	2,103,656	2,106,136	+0.12%
5 MiB	6,323,528	6,325,880	+0.04%

From 1 MiB up, allocation is now within 2.5 KB of develop. Small and medium files keep the savings.

I added testLargeFileAllocatesAtMostOneChunkBeyondItsLength, which caps allocation for a 1.5 MiB file at its length plus one chunk. It fails on the previous commit (3,677,560 bytes) and passes now.