On servers where process CPU time is limited, if the indexcontent.php cronjob exceeds the CPU time, all the changes to database it made are rolled back, thus, no new content is being indexed at all, IF the queue of Objects grows long enough to cause timeout.

The indexing is performed in loop, iterating over ContentObjects to be indexed, and there is $db->begin();, and matching $db->commit(); is at the end of loop. Also, the list of ContentObjects to be indexed is cleared after the loop is over, right before the commit.

The patch attached changes the behavior so every ContentObject is indexed in a separate transaction, and associated entry is removed from `ezpending_actions` alongside.

Steps to reproduce

On server with CPU time limit for processes, set ``DelayedIndexing' in ``[SearchSettings]'' in site.ini to true, enable ``indexcontent'' cronjob, and add a long list of objects to be indexed to `ezpending_actions'.

IF the queue of Objects grows long enough to cause timeout, when the process responsible for indexing times out, all the changes it made are rolled bacin in the database, and next time it starts from beginning.