Resolves: bug 459850
    Bug Description: replica_generate_next_csn opcsn adjustment errors during concurrent MMR load
    Reviewed by: nhosoi (Thanks!)
    Fix Description: In csngen_adjust_time, even if the time diff <= remote_offset, we still need to
    keep track of it and use it so that we generate CSNs that have the same
    timestamp as the remote CSN.  We use the local_offset to store that time diff.
    This sort of fits the semantics of local_offset as the diff is usually caused
    by the sampled time update thread running slightly behind, not in sync with the remote server.
    The code in _csngen_adjust_local_time will take the local_offset into
    consideration when updating the sampled time.  One thing we have to be careful
    of is to _not_ reset the sequence number if the new generated time will be the
    same as the old generated time.  If the old time is the same as the new time,
    we have to preserve the sequence number so that the next CSN generated will be greater than the previous one.
    The sequence number must be reset if
    the time was increased.  The right thing to do is set the sequence number to
    the remote sequence number + 1, in the case where we have advanced the time.
    If we have not advanced the time, we can't make the sequence number less,
    because we would then issue CSNs less than or equal to CSNs already issued.
    
    In csngen_adjust_time, we have to take care to reset the seqnum properly - if the new timestamp is greater than the old timestamp, we
    set the sequence number to be the remote + 1, regardless of whether or not the
    remote seq is < or > than the current seq.
    
    With this patch, running the replication stress test, I do not see any time
    skew, I do not see any generate_next_csn error messages, I do not see any
    duplicate or retrograde CSN issuance.
    Platforms tested: RHEL5, Fedora 8, Fedora 9
    Flag Day: no
    Doc impact: no