Wait for the renamed entry before reading the naming conflict monitor

[vharseko]

UpdateOperationTest.namingConflicts fails intermittently in CI with

java.lang.AssertionError: expected [1] but found [2]
	at org.opends.server.replication.UpdateOperationTest.namingConflicts(UpdateOperationTest.java:756)

seen on JDK 25 in run 32375391745, where the other JDKs of the same run passed.

Why

The clean-up after the two-adds-one-DN case publishes a delete for each entry and then waits for each DN to go:

broker.publish(new DeleteMsg(personWithUUIDEntry.getName(),      gen.newCSN(), user1entryUUID));
broker.publish(new DeleteMsg(personWithSecondUniqueID.getName(), gen.newCSN(), user1entrysecondUUID));

assertNull(getEntry(personWithUUIDEntry.getName(), 10000, false), ...);
assertNull(getEntry(personWithSecondUniqueID.getName(), 10000, false), ...);

Both entries were created with the same DN — personWithSecondUniqueID is built at user1dn, the DN of personWithUUIDEntry — and the conflicting one has since been renamed by the test to entryuuid=<user1entrysecondUUID> + user1dn. So both waits watch user1dn and both return the moment the first delete is replayed. Nothing waits for the second.

The second delete is the one with a conflict to solve: its DN holds no entry any more, so solveNamingConflict(DeleteOperation) finds the renamed entry by entryUUID and counts a resolved naming conflict before replaying the delete against the new DN. The next section snapshots that counter with updateMonitorCount(baseDN, resolvedMonitorAttr) and asserts a delta of 1 for the conflict it raises itself — so a count that arrives late is read as its own, and the assertion sees 2.

Fix

Wait for the DN the rename gave the entry. The count is taken before the replayed delete, so an entry gone from that DN means the count is already in the monitor.

The other clean-up block in the same method waits on a distinct DN per delete and is not affected.

Verification

mvn -pl opendj-server-legacy verify -Pprecommit -Dit.test='UpdateOperationTest#namingConflicts' — Tests run: 1, Failures: 0, Errors: 0.