Generating contextCSN on a newly adopted DB

[Ondřej Kuzník <ondra@mistotebe.net>]

Dealing with ITS#9015 has lead me to question part of the ITS#8281 fix
in cd8ff37629012c1676ef79de164a159da9b2ae89 - the part that refuses to
generate a contextCSN on a DB without one.

When syncprov is adopting a database that has never been managed by it,
it will only generate a new contexCSN if it's a standalone master (its
serverID is zero and replicates from noone). But people can and do add a
new database on a multimaster node expecting things to work OK, not
something that happens now, even worse, we can lie to the consumer and
say the DB is empty just because its contextCSN is.

AFAIK, the root cause of ITS#8281 (as reported) was diagnosed to be two
servers with the same serverID - not something we can or want to
support.

So my reaction is to make sure we always have a contextCSN (doesn't have
to contain our own serverID yet), generating it if not unless we're
running with SLAP_SINGLE_SHADOW(be) which means we might be a cascading
replica.

Is there a scenario that would break things? How about starting with an
empty DB, should we still put a contextCSN there?

Thanks,

-- 
Ondřej Kuzník
Senior Software Engineer
Symas Corporation                       http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP