QueryBuilder::setForwardOnly: use ForwardOnly mode for sql query

* less RAM
Akonadi::Server: add a benchmark fetch test for a popolated collection
handler::list: CollectionAttributs values are QByteArray

We should read/write them as QByteArray and not as QString
make Akonadi::Server::Connection to build for 12.04
Preserve local-only flags during MERGE

Some flags are never synced to server (because the server does not
support it for instance), so the resource cannot know about them when
syncing changes in the Item (another flags change, payload change,
whatever) and since ItemSync always crates non-incremental flags merging,
we would lost these local-only flags.

This hack ensures, that during MERGE when we have non-incremental flags
changes, certain local flags ($ATTACHMENT, $WATCHED, $INVITATION, ...)
are preserved.
Reduced notification compression.

This are three squashed commits:

Remove notification compression algorithm

The compression does not have much sense nowadays, as we rarely end up in
situation where merging notifications would result in performance improvement
(mostly because the most intensive operations now use batch notifications).
The only actual remaining use for the compression algorithm is in case of removal:

If there is a notification in the queue for a certain Item, and a removal
notification for the same Item is appended to the queue, it means that the Item
no longer exists in Akonadi and at time the first notification is delivered to
Monitor, EntityCache will no longer be able to retrieve the Item, which renders
the notification useless and we need to remove it to prevent EntityCache from
getting Item/CollectionFetchJob error.

However when massive removal operation takes place (in case of Collections that
is, removal of Items is again delivered as Batch notification), the queue has
to be iterated over and over again - and as the queue grows, the algorithm
stops being an optimization and instead becomes a bottleneck.

For that reason we dicided to remove the compression algorithm completely and
instead make sure, that Monitor (and EntityCache) on the client side can
properly handle the case of Item/Collection no longer existing in Akonadi at
the time the Notification is delivered.

Bring back notification compression - at lest partially

Turned out that adding a new Collection generates one ADD and several
(usually 3 in my case) MODIFY notifications - since the MODIFY is
expensive and slows down initial sync, we compress it ito one notification again.

All other notifications are dispatched directly without any compression.

Notification compression: further optimization to minimalize worst-case scenarios

We are now iterating over the list of pending notifications in reverse order,
because it's more probably that compressable notifications are at the end of
the queue rather at the beginning.

Iterating from the end also means that once we reach Add notification for the
same collection, we can break immediatelly and don't have to iterate through the
rest of the list, since there can be no other notifications for this Collection
before "Add"
NotificationCompression: Limit search to last 10 items, and remove modify after add.

Removing the modify after add avoids that each collection is initially indexed twice.