syncrepl simplification

[Howard Chu <hyc@symas.com>]

There seems to still be a lot of unnecessary complexity in the syncrepl 
implementation. I'm rather skeptical of the value of having multiple 
consumer contexts within a single database. A single database like this 
cannot be used in a cascade to provide for other consumers, because 
there can only be one provider context and there is no assurance that 
the CSNs of the multiple consumers will be in any way coherent. As such, 
it makes the most sense to keep only one consumer context per 
database/naming context.

If we restrict the implementation to using only one consumer per 
context, then we can collapse the consumer contextCSN into the suffix 
entry, the same as was done with the provider context. Then we don't 
need to mess around with the slapadd options for promotion/demotion of 
provider/consumer since the same contextCSN info is used in all cases. 
This would allow us to remove the -p, -r, -w, and -i options from 
slapadd, and save a lot of administrative overhead re: 
promotion/demotion. (Actually I would keep the "-w" option to write the 
contextCSN. Saves time for the provider, and allows the resulting 
database to be slapcat'd and immediately slapadd'd into any consumers 
without any more fuss.)

Comments? I guess I'm looking for a compelling example of the usefulness 
of multiple consumers in a single database. I suspect any example can be 
accomodated using separate databases and the glue overlay, and the glue 
approach probably provides more efficient security/isolation anyway.

--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support