Fix race in BatchApiOpImpl CompletionListener.start() causing flaky IllegalThreadStateException (#105)

[vharseko]

Fixes#105.

Problem

AsyncRemoteSecureConnectorInfoManagerTest.testSerialBatchWithError fails intermittently in CI with IllegalThreadStateException thrown from BatchApiOpImpl$InternalRequest$CompletionListener.start().

CompletionListener.start() guarded Thread.start() with a plain, unsynchronized boolean. The listener is started from two branches of handleOperationResponseMessages — the batch-token branch and the "complete" branch — and operation responses are dispatched on a thread pool, so when the token and complete messages arrive close together, two pool threads can both observe running == false and both call super.start() (check-then-act race). The second Thread.start() throws, the exception propagates out of the message-processing task, and the batch result is lost.

Fix

• Guard the start with an AtomicBoolean CAS — only the first caller may actually start the thread.
• Make returnTokenvolatile and publish it fully populated (build in a local, assign last): the CompletionListener thread spins on returnToken == null, and when it lost the start() race there was no happens-before edge, so it could observe a stale null or a partially built token.

Testing

AsyncRemoteSecureConnectorInfoManagerTest (connector-server-grizzly, includes testSerialBatchWithError) run 4 times locally: Tests run: 14, Failures: 0, Errors: 0 each time.