carry it. This in preparation to support LDAP v3 MODDN
request.

int add_values LDAP_P(( Entry *e, LDAPMod *mod, char *dn ));
int delete_values LDAP_P(( Entry *e, LDAPMod *mod, char *dn ));
int replace_values LDAP_P(( Entry *e, LDAPMod *mod, char *dn ));
to
int bdb2i_add_values LDAP_P(( Entry *e, LDAPMod *mod, char *dn ));
int bdb2i_delete_values LDAP_P(( Entry *e, LDAPMod *mod, char *dn ));
int bdb2i_replace_values LDAP_P(( Entry *e, LDAPMod *mod, char *dn ));
So that ldbm and db2 backends can coexist.

int add_values LDAP_P(( Entry *e, LDAPMod *mod, char *dn ));
int delete_values LDAP_P(( Entry *e, LDAPMod *mod, char *dn ));
int replace_values LDAP_P(( Entry *e, LDAPMod *mod, char *dn ));
to
int bdb2i_add_values LDAP_P(( Entry *e, LDAPMod *mod, char *dn ));
int bdb2i_delete_values LDAP_P(( Entry *e, LDAPMod *mod, char *dn ));
int bdb2i_replace_values LDAP_P(( Entry *e, LDAPMod *mod, char *dn ));
So that ldbm and db2 backend can coexist

8.9 style configuration via MAILER(mail500).

same code (commented out).

v3 MODDN (MODRDN) operation on the client side.

a MODDN or MODRDN request depending on the newSuperior parameter.

ldapmodrdn so that it can take the newparent parameter. (Check -s option)

utility functions added to support the modrdn v3 implementation.
These parse and rdn of the form "attribute_type = attribute_value"
returning "attribute_type" and "attribute_value" respectively.

are needed in the implementation of modrdn v3.

used in implementing modrdn v3.

construction which may be useful later when adding new tags. This
in preparation to support moddn v3.

used in implementing modrdn v3.

for implementing modrdn v3.

from what the current code can handle.

Use pthread_*attr_default.
Don't use a void return value from pthread_yield.

which only part of a LDAPMessage is available on a socket.

The server-code seemed to handle this correctly already, so I didn't touch
it.

My apologies for the hack in ber_get_next :-).