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 #47649 - Server hangs in cos_cache when adding a user entry

Bug description: cos_dn_defs_cb reads cosDefinition and sets up the cos
Definition part of cos cache.  In the function, when processing
cosAttribute, cosTargetTree and cosTemlpateDn are missing, it sets the
parent dn of the cos definition dn.  This parent setting is needed only
when the 2 attributes are completely missing from the cos definition.
But if the attributes are located below cosAttribute (see the Example
cos definition), in addition to "cn=cosTemplates,ou=people,dc=example,
dc=com", the parent of "cn=generatePostalCode,ou=People,dc=example,dc=com"
is added to the cos cache as cosTemplateDn.
  Example cos definition:
    dn: cn=generatePostalCode,ou=People,dc=example,dc=com
    description: generate postalCode attr based on location
    objectClass: top
    objectClass: ldapsubentry
    objectClass: cossuperdefinition
    objectClass: cosClassicDefinition
    cosAttribute: postalCode
    costemplatedn: cn=cosTemplates,ou=people,dc=example,dc=com
    cosSpecifier: l
    cn: generatePostalCode
The mistakenly added cosTemplatedDn makes adding an entry under ou=People
notify recreating the cos cache.  The notification needs to be outside of
backend transaction since it causes a deadlock with the cos_cache_wait_
on_change thread which cannot read the DB due to the transaction but holds
the lock that the notifier thread is waiting for.

Fix description: The parent of the cos definition dn is set to the
cosTargetTree and the cosTemlpateDn, only when the attributes are
completely missing.

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

Reviewed by rmeggins@redhat.com (Thank you, Rich!!)
(cherry picked from commit 1e52401d3abd0377f55676f4a1508a02aaa7f955)
(cherry picked from commit 01c0794cde7eb91a1a4e477a0286533df4a4ae38)

(cherry picked from commit 1ebad4bd50fb1483998a32b5d3e232e89aeda0f7)
Ticket #47750 - Creating a glue fails if one above level is a conflict or missing

Including the fix for 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 and slapi_rdn_is_
conflict, and slapi_is_special_rdn are added.

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

Reviewed by mreynolds@redhat.com (Thank you, Mark!!)
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)
(cherry picked from commit 86b34ca0a002715a263a56b1e8c870dd3035bce4)
(cherry picked from commit efa23ced2a6e3de3389d9b801329066f511bc38c)
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