Ticket 47541 - Replication of the schema may overwrite
 consumer 'attributetypes' even                 if
 consumer definition is a superset

Bug Description:  Need to check consumer attributetypes to make sure it doesn't get
                  overwritten if it is a superset.

Fix Description:  First, extended the attribute syntax struct to make it a double
                  linked list.  This allows us to easily look through all the attributeTypes.
                  Then check for supersets by looking at single vs multi-valued, and
                  syntax oid's.  Matching rules are not being evalauated at this time.

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

Reveiwed by: rmeggins(Thanks!)
Ticket 47541 - Fix Jenkins errors

Removed unused variables.

https://fedorahosted.org/389//ticket/47541
Ticket 47676 : Replication of the schema fails 'master branch' -> 1.2.11 or 1.3.1

Bug Description:

	Since https://fedorahosted.org/389/ticket/47490 and https://fedorahosted.org/389/ticket/47541 a supplier schema is
	pushed to the consumer at the condition that the consumer schema is not a superset of the supplier schema.

	With https://fedorahosted.org/389/ticket/47647, the objectclass 'print-uri' has been removed from master.
	Starting in 1.3.1, unhashed#user#password pseudo attribute as been removed from the schema.

	A consequence is that replication of the schema fails: master->1.2.11 and master->1.3.1

Fix Description:

	Replication plugin initialization (multimaster_start) creates the three following entries
		dn: cn=replSchema,cn=config
		objectClass: top
		objectClass: nsSchemaPolicy
		cn: replSchema

		dn: cn=consumerUpdatePolicy,cn=replSchema,cn=config
		objectClass: top
		objectClass: nsSchemaPolicy
		cn: consumerUpdatePolicy
		schemaUpdateObjectclassAccept: printer-uri-oid
		schemaUpdateAttributeAccept: 2.16.840.1.113730.3.1.2110
		schemaUpdateObjectclassReject: dummy-objectclass-name
		schemaUpdateAttributeReject: dummy-attribute-name

		dn: cn=supplierUpdatePolicy,cn=replSchema,cn=config
		objectClass: top
		objectClass: nsSchemaPolicy
		cn: supplierUpdatePolicy
		schemaUpdateObjectclassAccept: printer-uri-oid
		schemaUpdateAttributeAccept: 2.16.840.1.113730.3.1.2110
		schemaUpdateObjectclassReject: dummy-objectclass-name
		schemaUpdateAttributeReject: dummy-attribute-name

	schemaUpdateObjectclassAccept, schemaUpdateAttributeAccept, schemaUpdateObjectclassReject and schemaUpdateAttributeReject
	are optional multi-valued attribute.
	The values are strings representing objectclass/attribute name or OID.

	During a replication session, if the consumer schema needs to be updated (because nsSchemaCSN differs) the checkings are:
		On supplier side:
			OBJECTCLASSES
			For each objectclass OC in the consumer schema:
			if it exists in 'cn=supplierUpdatePolicy,cn=replSchema,cn=config'
				schemaUpdateObjectclassAccept: <oc_name or oc_oid>
				then this OC is "accepted" without checking that
					- OC exists in supplier schema
					- supplier's OC >= consumer's OC

				schemaUpdateObjectclassReject: <oc_name or oc_oid>
				then the supplier schema is not pushed (rejected)

			If none of these values exists, then it does the "normal" processing to determine if the schema can be updated:
				(if Supplier's OC < consumer's OC then schema is not pushed)

			ATTRIBUTES
			It does the same processing as above for each attribute, looking for values
				schemaUpdateAttributeAccept and schemaUpdateAttributeReject

		On consumer side:

			OBJECTCLASSES
			It does the same processing as above for each OC in the supplier schema, checking against
			entry 'cn=consumerUpdatePolicy,cn=replSchema,cn=config'

			ATTRIBUTES
			It does the same processing as above for each AT in the supplier schema, checking against
			entry 'cn=consumerUpdatePolicy,cn=replSchema,cn=config'

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

Reviewed by: Rich Megginson (Thanks Rich!)

Platforms tested: F17/F19(jenkins)

Flag Day: no

Doc impact: no
Ticket 47676 : (cont.) Replication of the schema fails 'master branch' -> 1.2.11 or 1.3.1

Bug Description:
	Pick up the wrong OID for nsSchemaPolicy objectclass

Fix Description:
	Replace 2.16.840.1.113730.3.2.115 with 2.16.840.1.113730.3.2.328

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

Reviewed by:  Rich Meggison (thanks again Rich)

Platforms tested: F17

Flag Day: no

Doc impact: no
Ticket 47721 - Schema Replication Issue

Bug Description:
	During a replication session, a supplier may send its schema in order to overwrite a consumer schema.
	Since https://fedorahosted.org/389/ticket/47490, a replica acting as a consumer rejects the schema
	if it evaluates that its own schema is a superset of the received schema. Also with 47490, a replica
	acting as a supplier will not send its schema if it evaluates that the consumer schema is a superset
	of its own schema.
	This creates an issue if the schema on both side contains definitions that the other side ignore, or
	that extend the other side definition. In that case each side will keep its own schema.

Fix Description:
	http://directory.fedoraproject.org/wiki/Replication_of_custom_schema_(ticket_47721)
	When acting as a consumer, it may receive a schema during a replication session.
	It then evaluates each definition (objectclasses/attritetypes) and if a definition
	is new or extend a current definition, then it add the definitions in its schema (in 99user.ldif)

	When acting as a supplier, it looks up the consumer schema. Whether it decides to send
	its own schema or not, it first evaluates each definition (objectclasses/attritetypes) and
	if a definition is new or extend a current definition, then it add the definitions in its schema (in 99user.ldif)

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

Reviewed by: Rich Megginson (Big thanks Rich for the review)

Platforms tested:
	for 389-DS CI tests: F17, F19 (jenkins)
	for Dogtag: manual test case master/clone - F19 (10.0.7) / F20 (10.1.1)
	for IPA: F20 3.3.5 manual test case and unit tests

Flag Day: no
Ticket 47721 - Schema Replication Issue (follow up + cleanup)

Fix Description:
	Fix test cases 47490
	Fix test cases 47553 (py.test fixture commented)
	Fix test cases 47619 (task timeout not yet in lib389)
	Forget to change (char *) into (const char *)

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

Reviewed by: Rich Megginson

Platforms tested: F19
Flag Day: no

Doc impact: no
Ticket 47721 - Schema Replication Issue (follow up)

Fix Description:
	Forget to change (char *) into (const char *)

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

Reviewed by: Rich Megginson

Platforms tested: F19
Flag Day: no

Doc impact: no
Ticket 47670 - Aci warnings in error log

Bug Description:  Some aci warnings are unneccesarily written to the
                  error log.

Fix Description:  Lower the log messaages from SLAPI_LOG_FATAL to SLAPI_LOG_ACL

Patch provided by: chatfield(Thanks!)

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

Reviewed by: nhosoi(Thanks!)

(cherry picked from commit 4f14e7df8215e30d6dd1205638886a877f46a70c)
Ticket #47720 - Normalization from old DN format to New DN format doesnt handel condition properly when there is space in a suffix after the seperator operator.

Description: DN normalizer (slapi_dn_normalize_ext) follows RFC 4514
and keeps a white space if the RDN attribute type is not based on the
DN syntax.  But Directory server's configuration entry sometimes uses
"cn" to store a DN value (e.g., dn: cn="dc=A,dc=com",cn=mapping tree,
cn=config), which expects the value of cn treated as DN although cn
is not a DN syntax type.  To solve the problem, this patch introduces
a configuration parameter "nsslapd-cn-uses-dn-syntax-in-dns" to "cn=
config" which takes "on" or "off".  If "on" is set, if the value of
cn under "cn=config" is quoted, it's processed as DN.  By default,
  nsslapd-cn-uses-dn-syntax-in-dns: off

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

Reviewed by mreynolds@redhat.com (Thank you, Mark!!)
(cherry picked from commit b22970e26da3f812c7ff6c177583603005eb3702)