[#748] stabilize flaky GrizzlyLDAPConnectionFactoryTestCase.testResourceManagement

[vharseko]

Fixes #748.

Problem

GrizzlyLDAPConnectionFactoryTestCase.testResourceManagement (regression test for OPENDJ-1156) intermittently times out on the macos-latest, 11 CI matrix job, breaking otherwise-green builds. The test runs 100 iterations, each opening a connection, triggering a remote disconnect(), and waiting up to TEST_TIMEOUT = 30s for the client-side error notification (listener.awaitError(...)).

Root cause

This is delivery latency, not a lost notification. The async connection-error path is correct for every event ordering:

• CompletionHandlerAdapter.completed() registers LDAP_CONNECTION_ATTR (via registerConnection) before the connection promise is fulfilled, so by the time getConnection() returns and disconnect() is called, the client connection is fully registered and LDAPClientFilter.handleClose() finds a non-null ldapConnection → GrizzlyLDAPConnection.close() fires handleConnectionError.
• If the failure were observed before the listener is added, addConnectionEventListener() notifies it immediately via the isFailed branch.

Both orderings deliver exactly one notification, so no product code is at fault. On a slow/loaded macOS + Java 11 runner one of the 100 iterations simply exceeded the 30s deadline (elapsed time was 30.08s). 8 of 9 matrix jobs passed — an environment symptom, not a functional regression.

Fix

Raise the shared TEST_TIMEOUT from 30s to 60s. It is a generous upper bound, not an expected duration — in the normal case the awaited latch releases within milliseconds, so this only takes effect under runner slowness and trades a slower failure for far fewer false-negative builds. ITERATIONS stays at 100 to preserve the OPENDJ-1156 race coverage. No product code changed.

Verification

mvn -pl opendj-grizzly surefire:test -Dtest='GrizzlyLDAPConnectionFactoryTestCase#testResourceManagement' → all tests passed.