Ticket 568 - make usage of transaction batch flush durable
    
    Bug Description:  if a transaction batch value >1 is specified
    	in a txn commit the txn log is ionly flushed if the batch
    	limit is reached. This can increase performance, but since
    	the operation is acknowleded to the client, a crash before
    	flushing the log would violate the durability condition.
    
    Fix Description:   to allow txn log flushing in batches, if batch-limit > 0
    	the flushing is done in the logflush thread. In a txn commit
    	a worker thread adds its transaction to the list of txns to flush,
    	eventually notifies the logflush thread and waits until logflushthread
    	confirms that the txn was flushed. only then the worker thread
    	continues and acknowledges success to the client.
    	There needs to be care that the txn logs are flushed frequently by the
    	logflush thread, even if there are less than the batch limit of txns
    	are waiting to be flushed.
    	one condition is base on active txns vs waiting txns, if there are no more
    	outstanding txns do flush.
    	the other condition is tiome based on two configurable timers:
    	-  the logflush thread sleeps on a condition variable until it gets notified
    	   by a worker thread that the batch limit is exceeded or the interval has passed
    	-  if it awakes it checks when the last flush was done and either if it is longer
    	   than th esecond timeer or the batch limit is reached the txns are flushed
    
    	The fix provided here makes the use of batch vals safe, but to get a performance
    	benefit further changes are required. Right now the txn is started and committed
    	inside dblayer_lock|unlock_backend, so txns cannot accumulate to be flushed.
    	So the order of txn and backend locking needs to be reveresed, or eventually the
    	code in the worker thread handling the synchronization could be move close to
    	sending the result to the client. But this optimization question ahs been moved
    	to a seperate ticket: 47358
    
    	The fix includes a minor change for the trickle thread, it is only started if trickling
    	is required (trickle percentage > 0).
    
    https://fedorahosted.org/389/ticket/568
    
    Reviewed by: Noriko, Thanks