Re: (ITS#7384) Assert Crash in ppolicy_ctrls_cleanup

[ryan@nardis.ca]

Just noting that one way to reproduce this assert reliably is to bind to 
an existing entry, through the relay, with an incorrect password.

The important part of the config is:

database mdb
suffix dc=example,dc=com
[...]

overlay ppolicy

database relay
suffix o=example

overlay rwm
rwm-suffixmassage o=example dc=example,dc=com

overlay ppolicy

Then, binding through the relay:

$ ldapwhoami -x -D uid=test,o=example -w zzz -e ppolicy

slapd: ppolicy.c:912: ctrls_cleanup: Assertion `rs->sr_ctrls != ((void *)0)' failed.

Same as when someone accidentally attaches two ppolicy instances to a 
single database. Not totally sure, but I suspect it's wrong here too: I 
don't see what the ppolicy attached to the relay is supposed to add in 
this case. I guess in theory they could have different configuration?  
wrt. e.g. ppolicy_use_lockout, or even pwdLockout/pwdMustChange via a 
different ppolicy_default...

Wondering if it would make sense for add_passcontrol to look for a 
ppolicy control already existing on the op, and try to fail gracefully 
if so, instead of hitting this on the way out.

Binding to the same entry with the correct password...

$ ldapwhoami -x -D uid=test,o=example -w test -e ppolicy

currently hits the same segfault reported in ITS#7966.