f9638bb Ticket 51190 - SyncRepl plugin provides a wrong cookie

Authored and Committed by tbordaz 3 years ago
    Ticket 51190 - SyncRepl plugin provides a wrong cookie
    
    Bug description:
    	A sync repl thread is similar to persistent search thread.
            The server is communicating with the sync repl thread with
            an ordered queue of updates.
            Updates are written in the queue by post op callbacks.
    	Sync repl thread waits/reads the queue, retrieve the updates
    	from the retroCL, checks if target entry matches the
    	request (scope/filter) and send back the entry/update to
            the sync repl client.
    
            Several issues regarding the way order of the updates in
    	the queue:
    
    	(1) When an update generates nested updates (automemeber,
            memberof,...) the order of the updates in the queue is
            not following the order of applied updates. The consequence
    	is that the cookie (containing the update nubmer) can be wrong.
            It can contains jumps, disorder and invalid number (-1).
    
    	When an update fails (nested or primary update), none of the
            updates should be pushed to sync_repl queue
    
    	(2) The plugin callback on updates are POSTOP, so if there are
            two direct updates, there is a possibility that the callback
            of the second update (and its nested updates) are enqueued
            before the first update. In such case the sync_repl thread
            may skip some updates and/or fail to retrieve update from
            retroCL (cookie.update_no=-1)
    
    Fix description:
    	The fix does
            (1) implements a pending list of updates (in the thread
    	private space "get_thread_primary_op").
            The first in the pending list is the primary update then
            the others are the nested updates.
            A new operation (betxn_preop) registers the operation at
            the end of the pending list with the state OPERATION_PL_PENDING.
            It requires to registers new callbacks (sync_betxn_preop_init)
    
            During be_postop (see below) callbacks flags the pending
            updates as OPERATION_PL_SUCCEEDED or OPERATION_PL_FAILED
            depending on the operatione result.
    	When no more pending updates are OPERATION_PL_PENDING,
            then depending of the result of the primary update
            (OPERATION_PL_SUCCEEDED or OPERATION_PL_FAILED) the
            updates are moved to the sync_repl queue.
    
    	(2) The postop plugin callbacks are now be_postop
    
    https://pagure.io/389-ds-base/issue/51190
    
    Reviewed by:  Mark Reynolds, Simon Pichugin, William Brown (Thanks)
    
    Platforms tested: F31