Ticket #47919 - ldbm_back_modify SLAPI_PLUGIN_BE_PRE_MODIFY_FN does not return even if one of the preop plugins fails.

Bug Description: In ldbm_back_modify, if one of the be_preop plugins
called at SLAPI_PLUGIN_BE_PRE_MODIFY_FN fail, ldbm_back_modify does
not return there but go to the real modify operation.

Fix Description: If an error is returned from be_preop plugins in
ldbm_back_modify, it returns the error there and does not proceed
the modify operation.

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

Reviewed by mreynolds@redhat.com (Thank you, Mark!!)

(cherry picked from commit cb173814ec579fafbfef515738c16a986a9749cd)
(cherry picked from commit 17294432e95bdb30c6816cefa7be5035df818a43)
Ticket 47920: Encoding of SearchResultEntry is missing tag

Bug Description:
	The encoding of the PreReadControl,PostReadControl does not
	contain the tag (LDAP_RES_SEARCH_ENTRY = constructed+application).

	The server should return SearchResultEntry (http://tools.ietf.org/html/rfc4527 3.1 & 3.2)
	That is
		SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
			     objectName      LDAPDN,
			     attributes      PartialAttributeList }
Fix Description:
	Add the tag to the ber encoding

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

Reviewed by: Noriko (thanks !)

Platforms tested: F17

Flag Day: no

Doc impact: no
Ticket #47897 - Need to move slapi_pblock_set(pb, SLAPI_MODRDN_EXISTING_ENTRY, original_entry->ep_entry) prior to original_entry overwritten

Bug Description: In the DEADLOCK retry code in ldbm_back_modrdn,
SLAPI_MODRDN_EXISTING_ENTRY in pblock is reset with the new entry
to be renamed.  The location of the setting entry was inappropriate,
thus instead of the entry, but its backup is set in pblock.

Fix Description: Moving the slapi_pblock_set(SLAPI_MODRDN_EXISTING_
ENTRY) to the correct position.

Plus, in the DEADLOCK retry code, original_entry is duplicated and
used for the next loop.  The source of the duplication has to be
the clean entry before updated in the backend code, but in ldbm_add,
ldbm_modify, and ldbm_modrdn, the current entry was duplicated and
set to the original entry, which could have been updated in the
previous loop.  This patch fixes it, as well.

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

Reviewed by tbordaz@redhat.com (Thank you, Theirry!!)

(cherry picked from commit 2aabb017bd4eec6d30bf00486eb027f59129cf74)
(cherry picked from commit 2393a48021944230f5ebcf5363c0095b1c4679ab)
Ticket #47922 - dynamically added macro aci is not evaluated on the fly

Bug Description: When macro aci is dynamically added and if the aci's
macro target dn is not normalized, the following operation that requires
the aci could fail with Insufficient access since matching the target dn
and the macro target dn fails since the code expects normalized macro
target dn.

Fix Description: Before setting the macro target dn, process the dn by
slapi_create_dn_string_case.

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

Reviewed by lkrispen@redhat.com and rmeggins@redhat.com (Thank you, Ludwig and Rich!!)

(cherry picked from commit 07c1bc25508a9c1e71dd8e717fd4ce455ddfeff0)
(cherry picked from commit c6b397c8466fd0859c5404c946a82f240564076e)
Bump version to 1.3.2.24