change to acl_read module for supporting dirsync module

[Nadezhda Ivanova]

Hi Matthias,
Matthieu explained to me the logic of the dirsync implementation, so:
We cannot put dirsync module below acl_read, as dirsync alters the search
results based on whether they have been changed since the last replication,
and therefore attributes necessary for the access check could be missing
from the result.
We cannot make acl_read check for the original control instead of an
internal one, because dirsync module removes that control. I think it would
be messy to remove it in the acl_read instead. We cannot make acl_read skip
all checks if dirsync control is present, as there is a flag in the dirsync
control which requires the regular access checks to be made.
I suppose if the acl_read module got the SD, sid and objectclass with a
separate request that would not be an issue, but I specifically restructured
it some time ago to just add them to the original request and pass it down
for performance's sake.
Matthieu, as we discussed, replacing the internal control with a private
flag would be great if it's OK with everyone, as checking for controls
appears to be slow. Also, as we agreed, instead of removing replmetadata
mark it inaccessible, or design a better (faster) way to remove attributes
from the message and patch acl_read.

My experience with the acl_read module makes me believe that any module that
alters search results should be as high on the stack as possible to avoid
messing with the internal workings of other modules. The acl_read could not
be on top because it needed the work done by the extended_dn and ranged
modules. Because of this a lot of modules above it have to mark their
internal requests as trusted (still WIP). Its best not to repeat the story
with another module :).

Regards,
Nadya