Replication: AddMsg.addAttribute() swallows every exception, dropping the ds-sync-conflict marker

[vharseko]

AddMsg.addAttribute() (opendj-server-legacy/src/main/java/org/opends/server/replication/protocol/AddMsg.java:344-359) declares throws DecodeException and then catches everything:

try
{
  new LDAPAttribute(name, value).write(writer);
  encodedAttributes = byteBuilder.toByteArray();
}
catch(Exception e)
{
  // DO SOMETHING
}

Its one caller is LDAPReplicationDomain.addConflict(), which adds ds-sync-conflict to an entry conflict resolution could not place. If the write fails, encodedAttributes keeps the value it had: the entry is added under its conflict RDN without the marker which says why, and the repair tool has nothing to find it by. Nothing is logged.

Worth fixing on its own, and worth knowing before it is: solveNamingConflict() calls addConflict() after the operation has run, so a DecodeException which is allowed out of here reaches the replay's catch with an operation built. #892 made that safe - the give-up is keyed off op == null rather than off the exception type, so a failure past op.run() takes the ordinary failure road - but on any earlier revision it would be recorded as replayed, ServerState and all.

Found while reviewing #892 (CodeQL flags the empty catch as well).