Ticket 47792 - database plugins need a way to call betxn
 plugins

Bug Description:  Database plugins like "chaining" register their
                  own add/mod/delete/modrdn functions.  These new
                  operation functions do not call the be/betxn plugins.

Fix Description:  Created two new private functions to call the
                  pre & post be/betxn plugins.  Added these functions
                  to the chaining plugin.  Maybe in the future these
                  functions will be made public(slapi api).

                  Also fixed a harmless startup/initialization
                  memory leak.

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

Jenkins: passed.
Valgrind: passed.

Reviewed by: rmeggins & lkrispenz (Thanks!!)

(cherry picked from commit 9929b439b766e807ad77285e3b3babb514dde897)
Ticket 47793 - Server crashes if uniqueMember is invalid syntax and memberOf
               plugin is enabled.

Bug Description:  MemberOf assumes the DN value has the correct syntax, and
                  does not check the normalized value of that DN.  This
                  leads to dereferencing a NULL pointer and crash.

Fix Description:  Check the normalized value, and log a proper error.

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

Reviewed by: nhosoi(Thanks!)

(cherry picked from commit 6816e1155b28fb65fe294099336c4acbbac8ad77)
Ticket 47772 - fix coverity issue

12565 - resource leak
12564 - Explicit null dereferenced

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

Reviewed by: rmeggins(Thanks!)

(cherry picked from commit 24d44ba65398470fc8056b14b77b34b5d660f34e)
Ticket #47750 - Creating a glue fails if one above level is a conflict or missing;
Ticket #47696 - Large Searches Hang - Possibly entryrdn related

Bug Descriptions:
There were multiple issues to break the parent-child relationship when a
resurrect occurred.
When resurrecting a tombstone, there is a possibility that an entry having
the same name was already added.  In the case, the code consdered the entry
is already there, which confused the numsubordinates and tombstone-num-
subordinates count.  If it is detected, it creates a conflict glue entry
instead of a pure glue entry.  The 2 numsubordinates counts were also not
correctly updated in the resurrection case. When the entryrdn was introduced,
Slapi_RDN was held in the entry, which was not correctly updated in the
resurrect case.

Fix Descriptions:
[replication/urp.c]
urp_fixup_rename_entry sets the parent uniqueid if it is a RESURRECT mode
(called from tombstone_to_glue) as being done in urp_fixup_add_entry, which
is necessary to retrieve the correct parent in ldbm_back_modrdn.

[replication/urp_glue.c]
In create_glue_entry,
. there was a possibility to pass a tombstone DN (nsuniqueid=...,<DN>) is
  used to create a glue entry.  If found, the part is removed before passing
  it to create a glue entry.
. there is a possibility to create a glue entry fails due to the parent entry
  not found.  This occurs when the parent entry has turned to be a conflict
  entry.  In the case, instead of retrying the glue creation, it logs an
  error and returns.

[replication/urp_tombstone.c]
In tombstone_to_glue,
. turning a tombstone to an ordinary glue entry could fail with the entry
  already exists.  (Note: ldbm_back_add guarantees that the found entry has
  a different nsuniqueid from this tombstone has.)  This situation occurs an
  entry having the same dn could have been added/replicated by this moment.
  And the entry cannot be used for this tombstone to resurrect since the
  subordinates/tombstonesubordinates relationships get corrupted. To maintain
  the relationship properly, the tombstone is resurrected as a conflict, glue
  entry using urp_fixup_rename_entry.  If it still returns LDAP_ALREADY_EXISTS,
  it is assured the expected glue entry exists since the same nsuniqueid is
  shared.

[slapd/back-ldbm/ldbm_add.c]
In ldbm_back_add,
. in is_resurect_operation case, a SLAPI_ADD_EXISTING_DN_ENTRY entry and a
  SLAPI_ADD_EXISTING_UNIQUEID_ENTRY entry are identical, it returns SUCCESS
  instead of LDAP_ALREADY_EXISTS.
. in is_resurect_operation case, the DN is modified from the tombstone DN
  to the ordinary DN.  The DN is stored in e_sdn as well as in e_srdn in the
  Slapi_Entry.  The e_srdn part was not updated.  This patch fixes it and
  e_sdn and e_srdn are in sync.
. parent_update_on_childchange adjusts the count of numsubordinates and
  tombstonenumsubordinates.  It only took PARENTUPDATE_ADD|_DELETE operations.
  This patch adds PARENTUPDATE_RESURECT operation to increment numsubordinates
  and decrement tombstonenumsubordinates at the same time.
. in is_resurect_operation case, a tombstone to be replaced with a glue entry
  needs to be deleted from the entryrdn index, which was missing.

[slapd/back-ldbm/ldbm_delete.c]
. Check the target DN if it starts with "nsuniqueid=...,", if it is, log an
  error and returns.

[slapd/back-ldbm/ldbm_modrdn.c]
. If it is is_resurect_operation case, it allows to rename a tombstone entry.
  This is used to support to change a tombstone entry to a conflict glue entry
  in tombstone_to_glue.
. ldbm_back_modify checks if the renamed entry has children or not and if
  there are, they are updated to point to the renamed entry.  The check
  function slapi_entry_has_children was just checking the numsubordinates
  attribute type.  If a positive value is returned, it took care all the
  children including the tombstones, but if the renamed entry had tombstoned
  children only, it considered there were no children and the tombstoned
  children were not updated to point the renamed entry.  This patch fixes it.

[slapd/back-ldbm/ldbm_entryrdn.c]
. Added a flag to entryrdn_rename_subtree and entryrdn_get_subordinates to
  treat the given DN a tombstoned DN if it is.

In addition, helper APIs such as slapi_rdn_is_multivalued, slapi_rdn_is_
conflict, and slapi_is_special_rdn are added.

Ported from 389-ds-base-1.2.11.

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

Reviewed by mreynolds@redhat.com (Thank you, Mark!!)
(cherry picked from commit 160cb3f686e433c01532d28770b2977ec957e73e)
Ticket #47764 - Problem with deletion while replicated

Bug description: When checking a child entry on a node, it only
checked the first position, which was normally "deleted" if there
were no more children. But in some cases, a tombstoned child was
placed there.  If it occurred, even though there were no live child
any more, _entryrdn_delete_key returned "has children" and the delete
operation failed.

Fix description: This patch checks all the children of the to-be-
deleted node and if there is no child or all of them are tombstones,
it goes to the next process.  Also, the fixed a typo reported by
chatfield (Thank you!!)

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

Reviewed by chatfield and mreynolds@redhat.com (Thank you both!!)
(cherry picked from commit 832253ea96b83e7ebc16fe507d77090e87aed1c2)
Ticket 47787 - A replicated MOD fails (Unwilling to perform) if it targets a tombstone

Bug Description:
	A fix for https://fedorahosted.org/389/ticket/47396 prevents a MOD operation
	on a tombstone.
	A problem is that legacy version may allowed it or if a MOD entry and DEL entry occurs on different
	master, it may happen that a consumer receive a MOD on a tombstone.
	The server return 'Unwilling to perform' that may break replication.

Fix Description:
	Allows a MOD on tombstone, only if it comes from a replication session

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

Reviewed by: Rich Megginson (thanks)

Platforms tested: F17, F19

Flag Day: no

Doc impact: no