Description of problem:
Consider we have a topology like Master replicating to slave.
Master -> Salve
When we promote Slave to become serve the Master role, if we assign the same
replica ID(value of "nsDS5ReplicaId" ) as of the Master during promotion
operation. The dummy entry(the "cn=start iteration" entry) do not get logged in
the changelogdb file. But if we assign the different replicaID, the dummy entry
gets logged in the changelogdb file.

Version-Release number of selected component (if applicable):

How reproducible:
Frequently.

Steps to Reproduce:
1.Create the Master and Salve topology where master replicating to the Slave.
   Master -------------------> Slave
nsDS5ReplicaId: 10            nsDS5ReplicaId: 65535 ----> Original
===========================================
   Master   <No aggrement now> Salve(Now become new master after promotion)
                               nsDS5ReplicaId: 10( which is same as the master
                                                 replica ID)
Note: In this scenario, it doesn't create a changelogdb file along with the
Dummy entry
============================================
   Master   <No aggrement now> Salve(Now become new master after promotion)
                               nsDS5ReplicaId: 20( which is same as the master
                                                 replica ID)
Note: In this scenario, it creates a changelogdb file along with the Dummy
entry.
===========================================

2.Make sure that both Master and Slave are on sync.

3.Delete the replication agreement.

4. Promote the Slave to serve the Master role. Promotion steps are given below.
   - Delete Supplier DN (cn=suppdn,cn=config) from Slave
   - Delete ?cn=replica? entry for the suffix ?o=USA? using ldapmodify. As a
    result, it will delete the changelog file.
      Ex: dn: cn=replica,cn=o=USA,cn=mapping tree,cn=config
          changetype: delete
   - Modify the cn=o=USA ,cn=mapping tree,cn=config entry as below
      EX: dn: cn=o=USA,cn=mapping tree,cn=config
          changetype: modify
          replace: nsslapd-state
          nsslapd-state: backend

          dn: cn=o=USA,cn=mapping tree,cn=config
          changetype: modify
          delete: nsslapd-referral
  - Recreate the ?cn=replica? entry for the suffix as below.
      EX: dn: cn=replica,cn=o=USA,cn=mapping tree,cn=config
          changetype: add
          objectClass: nsds5replica
          objectClass: top
          nsDS5ReplicaRoot: o=USA
          nsDS5ReplicaType: 3
          nsDS5Flags: 1
          nsDS5ReplicaId: 10  ----> <Please assign the same ?nsDS5ReplicaId
value what master was having. In my case, Original master replica ID was 10.>
          nsds5ReplicaPurgeDelay: 1
          nsds5ReplicaTombstonePurgeInterval: -1
          cn: replica
5. Restart  slapd process. Now Slave become Master.

Actual results:
It will not create any change log file and also will not create any dummy entry
like below to mark the last change it was received ever. But if we assign a
different replica ID( value of "nsDS5ReplicaId" attribute, for example "20"
instead of "10"), we will see this entry being getting created along with the
changelogdb file.
dbid: 4eb10ac20004000a0000
        replgen: 1320225977 Wed Nov  2 14:56:17 2011
        csn: 4eb10ac20004000a0000
        uniqueid: 00000000-00000000-00000000-00000000
        dn: cn=start iteration
        operation: delete

Expected results:

It should create a chnagelogdb file along with the dummy entry if we assign the
same replica ID as of it master which it does in case of a new replica ID
assignment.
Additional info: