Bug 515329 - Multiple mods in one operation can result in an inconsistent replica
    
    https://bugzilla.redhat.com/show_bug.cgi?id=515329
    Resolves: bug 515329
    Bug Description: Multiple mods in one operation can result in an inconsistent replica
    Reviewed by: nkinder, nhosoi (Thanks!)
    Branch: master
    Fix Description: When a master is processing a list of mod ops in a single
    modify operation, all of which have the same CSN, the server processes them
    in the order specified.  When a replica processes this same operation, and
    has to merge this operation with other operations, it essentially processes
    the operations in CSN order, and loses the original order of the ops within
    each modify operation.  The function that initially receives the
    replicated op, entry_apply_mods_wsi(), has the original order, and enforces
    this order by incrementing the until now unused subsequence number in the
    CSN for each mod op.  However, it only does this if the operation has
    been replicated, and if the original CSN does not already have a
    subsequence number.
    One side effect is that the subsequence number is stored with the state
    information in the database, which does not appear to affect anything else,
    and things like state information purging still work correctly.
    I've verfied that the subsequence number does not end up in in the changelog,
    nor the RUV or other externally used CSNs.
    Platforms tested: RHEL6 x86_64
    Flag Day: no
    Doc impact: no