ItemSync: Fix full sync and transaction handling

* Ensure that checkDone doesn't start the next batch while we're still fetching
the items.
This bug was triggered only if setFullSyncItems was called at least twice in streaming
mode (therefore it only appeard on large imap folders where the items
we delivered in two batches, and only during the flag sync which is a full sync).
The first call triggered the ItemFetch, but while that was in progress,
the second call went via process() to checkDone(), which cleared mProcessingBatch
and immediately started a second parallel batch, and a third batch was started
by deliveryDone(). This resulted in the first two batches (20 items), appearing as new
(because the were processed before the local items were fetched), and the already locally
available items getting deleted, because they couldn't be removed from
mUnprocessedLocalIds (since they were processed before entering that list.

We use the job counter to lock, just like everywhere else.

* mTransactionJobs should not be checked in execute(), as it is already checked in
checkDone(), and the check in execute() is only valid when using
MultiTransactionMode.

* Adapted the test to the discovered problems.

* The fetchjobs need to be part of the transaction as well, as they are otherwise
not executed before the transactoin is complete.

REVIEW: 117608