Fix stack overflow in auto_batcher::new_id() under contention

[ihsandemir]

Fixes #1491

Problem

The macOS nightly aborts in AutoBatcherTest.concurrencySmokeTest with an AddressSanitizer stack-overflow on an executor thread (for example https://github.com/hazelcast/hazelcast-cpp-client/actions/runs/34794206547). The trace repeats the same four Boost frames up to the truncation limit:

future_unwrap_shared_state<...>::launch_continuation()      future.hpp:5432
shared_state<long long>::mark_finished_with_result_internal  future.hpp:611
shared_state_base::mark_finished_internal                    future.hpp:344
shared_state<long long>::do_continuation                     future.hpp:590

auto_batcher::new_id() retried a caller that lost the race for an ID from the fresh batch by returning new_id() from a launch::sync continuation and calling .unwrap(). Each lost round wrapped the caller's future in one more future_unwrap_shared_state. Boost completes that chain recursively on the thread that finishes the last fetch.

Waiters lose repeatedly because the fetch lambda publishes the new block before Boost marks the fetch future ready. A caller that gets an ID loops straight back into the lock-free fast path and drains the rest of the batch while the executor thread is still running the coalesced continuations one by one. One waiter can lose hundreds of rounds in a row. macOS gives secondary threads a 512 KiB stack, and ASan frames are large, so the cascade overflows.

Fix

Each caller's result now lives in one boost::promise<int64_t>:

• new_id() keeps the allocation-free fast path. Otherwise it creates a promise, returns its future and calls the new private try_get_id(p).
• try_get_id(p) tries the fast path, then joins or elects the single in-flight fetch (election code unchanged) and registers a void continuation on it.
• The continuation sets the value when it wins, sets the supplier's exception on failure, and posts try_get_id(p) back to the executor when it loses. Posting instead of calling inline also handles the case where the next fetch has already completed and a sync continuation would run on the current thread.

Nothing waits on the continuation's own future, so no chain forms and stack depth stays constant however many rounds a waiter loses. Single-flight fetching, coalescing and error propagation work as before, and callers see the same new_id() contract.

Test

AutoBatcherTest.starvedWaiterDoesNotOverflowTheStack reproduces the starvation on every run: 128 waiters, a supplier that takes 1 ms, batch size 3. All threads coalesce onto the in-flight fetch. When it completes, the first three continuations win and their threads re-register on the next fetch ahead of the continuations still queued, so the last waiter loses every round until the others use up their quota.

Verified on macOS arm64, Debug + ASan, the configuration of the failing job:

Check	Before	After
New regression test, 3 runs	crashed 3/3 (EXC_BAD_ACCESS in do_continuation)	passed 3/3
concurrencySmokeTest + new test, 12 concurrent processes	3/12 crashed	24/24 passed
FlakeIdGeneratorApiTest.*, AutoBatcherTest.*, FlakeIdBatchTest.* against a remote controller		11/11 passed

[JackPGreen]

took me a minute to get my head around it, but this is the problematic bit.