Ticket #47367 - (phase 1) ldapdelete returns non-leaf entry error while trying to remove a leaf entry

Bug description: Replication conflict confuses the numsubordinate count,
which leaves an entry that cannot be deleted even its subordinate entries
are all removed.

Fix description:
[urp.c] 1) get_dn_plus_uniqueid: a logic to create a conflict DN had a bug.
  It used to call slapi_sdn_get_rdn to get the rdn.  The function slapi_sdn_
  get_rdn blindly returned the "dn" field without checking whether the field
  is NULL or not.  Instead, this patch changes the interface of the helper
  function get_dn_plus_uniqueid and use the original Slapi_DN with slapi_sdn_
  get_dn, then generates the conflict DN "nsuniqueid=...+ <RDN>,<PARENT>".
  2) The urp calling timing was moved from SLAPI_PLUGIN_BE_TXN_PRE_* to
  SLAPI_PLUGIN_BE_PRE_*.  (Note: SLAPI_PLUGIN_BE_PRE_* is also in the
  backend transaction.)  This is necessary since urp needs to be done
  prior to parent checking.
[ldbm_add.c] Moved SLAPI_PLUGIN_BE_PRE_ADD_FN inside of the transaction.
  Other operations are already calling SLAPI_PLUGIN_BE_PRE function at the
  timing.
[ldbm_delete.c] There is a case a parent of a delete-candidate entry runs
  into a conflict and multiple parent entries exist.  Once it occurs, a
  parent entry found by the parent dn string may not be the entry which
  manages the numsubordinate count the delete-candidate entry belonging to.
  It confuses the numsubordinate counts and leaves an entry which cannot be
  deleted due to the numsubordinate count mismatch. This patch retrieves
  parent entry by parent id if it is available.
[ldbm_entryrdn.c] When traversing the DIT, a special treatment is needed
  for a tombstone entry. I.e, 2 RDNs (nsuniqueid=..., <RDN>) is treated as
  one RDN.  It should decrement the index (rdnidx) one more to point to the
  right position of the RDN array in Slapi_RDN.
[ldbm_search.c] When checking the scope of an entry in ldbm_back_next_
  search_entry_ext, a tombstone entry was not properly examined. This patch
  introduces a new slapi api slapi_sdn_scope_test_ext.
[dn.c] In slapi_sdn_get_rdn, use slapi_sdn_get_dn to get the dn value of
  Slapi_DN.  It was one cause of the problem in get_dn_plus_uniqueid (urp.c).
  This patch adds slapi_sdn_scope_test_ext, which takes flags to indicates
  the first argument dn is a tombstone sdn.  Also, this patch replaces
  "malloc + strcpy + strcat" with slapi_ch_smprintf to improve the
  readability of the code.
[rdn.c] This patch replaces "malloc + strcpy + strcat" with slapi_create_
  dn_string to normalize the newly added rdn and improve the readability of
  the code.

Reviewed by Rich (Thanks!!)

https://fedorahosted.org/389/ticket/47367
(cherry picked from commit 2f4f74b3d38eeb38f0794dfb2e880a95e7e9bd49)
(cherry picked from commit 690d58ba5870e7f0dd3ad6593c92a86771fc54d5)
Ticket #47367 - (phase 2) ldapdelete returns non-leaf entry error while trying to remove a leaf entry

Fix description:
1) Make sure add/modify/modrdn/delete plug-in callbacks return
SLAPI_PLUGIN_SUCCESS (==0) on SUCCESS and SLAPI_PLUGIN_FAILURE
(==-1) on FAILURE.  And set error code to SLAPI_RESULT_CODE in
pblock, if any.
2) replication: eliminated multimaster_betxnpreop_* which were
used for calling urp.  Urp needs to be processed at bepreop
timing.

Reviewed by Rich (Thank you!!)

https://fedorahosted.org/389/ticket/47367
(cherry picked from commit 733059713a5dfb72c844de1e3b9bc153d4ae6ccb)
(cherry picked from commit ad0a2cabe349368e0cc72155994569564ca71290)
Ticket #47424 - Replication problem with add-delete requests on single-valued attributes

https://fedorahosted.org/389/ticket/47424
Reviewed by: lkrispenz (Thanks!)
Branch: 389-ds-base-1.3.0
Fix Description: Change the single master resolve attr code to handle the
specific case of doing
add: newvalue
delete: oldvalue
Had to add a new API function - csn_compare_ext - to be able to compare CSNs
without the subsequence number.
Platforms tested: RHEL6 x86_64
Flag Day: no
Doc impact: no
(cherry picked from commit 16e6fc20b51d94a22d73036f2809315b118bd5a4)
Ticket #47435 - Very large entryusn values after enabling the USN plugin and the lastusn value is negative.

1. Bug description: The initial value of lastusn is -1, but since
the entryusn has the unsigned long long integer type, the server
returns 18446744073709551615 == 0XFFFFFFFFFFFFFFFF.

Fix description: The initial value "-1" is returned as it is.

2. Bug description: Entryusn syntax is defined as an integer in
the schema.  If negative values are accidentally stored in the
entryusn value in the database, it was casted to the unsigned
integer in the entryusn initialization code (usn_get_last_usn).

Fix description: When an entryusn value is retrieved from the
database, it's checked as a singed integer once and if it is
negative, it's replaced with the initial value "-1".

https://fedorahosted.org/389/ticket/47435

Reviewed by Mark and Rich (Thank you!!)
(cherry picked from commit c94da991450da486b2032815b867bd2548a1614c)