When a client tries to do a schema modification on a non schema master dc,
we get a inconsistent in memory schemaInfo.

In the module stack we have "samldb" before "schema_data".
The "samldb" tries to update the "schemaInfo" attribute
on schema changes, which replaces the schema_info on the global schema
before the operation is completed. Later the "schema_data" rejects
the change with UNWILLING_TO_PERFORM. This results in an
inconsistency between schema->schema_info and the stored (and also loaded)
schema.

As this structure is likely to be global and in process model
single shared with the drsuapi service.
Everybody replicating from us will detect a SCHEMA_MISMATCH
and replicates the schema from us, but will never be able to
get the revision we're advertising in drsuapi_DsReplicaOIDMapping_Ctr.

This may result in an endless loop on the pulling side.