[#868] Release the import/export context before notifying the initialize task

[vharseko]

Fixes #868.

ReplicationDomain terminated a total update by notifying the initialize task first and releasing the import/export context afterwards. Between the two, ieRunning() still reports true, so anything reacting to the completion — the task thread of a real InitializeTask, or ReplicationDomainTest.errorMsgFromSameMillisecondTerminatesPendingInitialize woken up on the listener thread's notification — can see its own total update rejected as a simultaneous import/export.

That window is what made the test fail in CI (run 32124729058, ubuntu-latest/26); the other 8 matrix jobs of the same run were green.

What changed

All three import-termination paths now go through one helper that releases the context before notifying the task:

private void completeInitializeTask(ImportExportContext ieCtx)
{
  releaseIEContext();
  if (ieCtx.initializeTask instanceof InitializeTask)
  {
    ((InitializeTask) ieCtx.initializeTask).updateTaskCompletionState(ieCtx.getException());
  }
}

• processErrorMsg() — the ErrorMsg answering a pending initialization (the path that flaked).
• abortStalledInitializeFromRemote() — the stalled-request watchdog from [#861] Fail fast when a total update request gets no answer #864.
• initialize() — the end of an import from a remote replica.

The reordering is safe: ieCtx stays reachable through the local reference and getException() reads that object, not the AtomicReference.

In initialize() the notification also moves from the try into the finally that releases the context. It used to sit after broker.publish(errorMsg), so a failure while notifying the exporter skipped updateTaskCompletionState() altogether and left the task waiting forever — the failure mode fixed in #861/#864. The "update the task must be the last thing" requirement refers to broker.reStart(false), which runs before this block, so it still holds. As a side effect the task is now also notified when the import fails before initFromTask is assigned (e.g. initializeCounters() throwing), where it previously got no notification at all. Remote-initiated imports carry no local task and are unaffected.

Tests

No test change: releaseIEContext() is a volatile write and the task notification gives happens-before, so the existing assertion becomes deterministic instead of racy. Relaxing it into a poll would have hidden the defect.

mvn -pl opendj-server-legacy -Pprecommit verify -Dit.test=ReplicationDomainTest — 12/12 green locally.