[C++] Harden synthetic OOM tests for mimalloc

[k8ika0s]

Closes #49280

Summary

This PR makes synthetic OOM unit tests allocator-stable when mimalloc is active.

It updates:

• cpp/src/arrow/buffer_test.cc
• cpp/src/arrow/memory_pool_test.h

Problem

These tests intentionally request extremely large allocations to force OutOfMemory.
Using near-max bounds can hit allocator-specific fatal behavior (especially with mimalloc)
before Arrow returns a normal OOM status, making tests environment-dependent.

What changed

1. In ResizeOOM and TestOOM, detect mimalloc backend and GTEST_SKIP() synthetic OOM assertions.
2. Clamp synthetic huge allocation upper bound to 1 << 48 (256 TB), which is still impossible in practice but avoids extreme allocator boundary paths.
3. Keep existing alignment-overflow guard (-63) and ASSERT_RAISES(OutOfMemory, ...) logic for non-mimalloc backends.

Why this approach

• Scope is intentionally minimal and test-only.
• Preserves the goal of OOM-path coverage where behavior is reliable.
• Removes allocator-fatal coupling from CI/unit-test expectations.

Risk / Compatibility

• No runtime library behavior change.
• No API/ABI impact.
• Test behavior only.

[github-actions]

Thanks for opening a pull request!

If this is not a minor PR. Could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose

Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project.

Then could you also rename the pull request title in the following format?

GH-${GITHUB_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

or

MINOR: [${COMPONENT}] ${SUMMARY}

See also:

• Other pull requests
• Contribution Guidelines - Contributing Overview

[alamb]

Can you please clear what actual problem are you solving?

Using near-max bounds can hit allocator-specific fatal behavior (especially with mimalloc)

Can or does? Did you hit such a case? If so, why is it an issue?

[k8ika0s]

Can you please clear what actual problem are you solving?

Using near-max bounds can hit allocator-specific fatal behavior (especially with mimalloc)

Can or does? Did you hit such a case? If so, why is it an issue?
Good question, especially with the overly strong wording I used...

the real issue was test instability/long-running behavior from using near-max synthetic allocation sizes, especially on large-memory s390x environments. the test intent is to verify Arrow’s OutOfMemory path, not allocator-specific extreme-size internals.

the mimalloc skip is only for this synthetic giant-size path; I can drop the skip and keep only the clamp if that’s preferred.

I mentioned s390x, which is part of a larger focus. I know there is previous open and closed work around s390x, but with upstream support stalling, my goal here is to take much smaller bite size approach to begin addressing issues still in the latest codebase. I would also agree that this change on its own seems like a very cheap attempt to get a contrib, which is not the intent.