Modrdn replication

[Pierangelo Masarati <ando@sys-net.it>]

ITS#4809 reports that when replicating modrdn via slurpd, operational
attributes don't get replicated.  This appears to be intrinsically
caused by the definition of the modrdn operation, which, unlike the
modify and add operations, doesn't contemplate the possibility to
add/modify attributes other than the naming ones.  So add/modify can be
easily exploited for replication by adding/modifying the write-related
operational attributes during replication, while modrdn can't.

Assuming there's any intention to fix slurpd replication until slurpd is
dismissed, we need to find a means to attach modification of
write-related operational attributes to a modrdn operation, to
complement the modrdn operation itself.

The proposed solution consists in explicitly modifying the necessary
(operational) attributes by means of an additional modify operation that
is attached to modrdn.  This may be occasionally useful regardless of
slurpd replication, which makes it more appealing for OpenLDAP
developers, so that the required effort wouldn't be just wasted by
slurpd dismissal.

The additional modify could be wrapped into a control's value, and that
control might be the "relax" control itself, so that the original
operation, augmented by the optional modify, would need to succeed as a
whole or abort, extending the capabilities of the "relax" control by
allowing extra modifications to be added, in order to preserve the
integrity of the object after the operation.

Comments?  p.