CollectionStatistics lives in a separate thread. Returning the Statistics
structure as a reference to other threads than means that the structure
can be deleted in the CollectionStatistics thread while other threads
are still holding a reference. We now return a copy of the Statistics
struct instead, it's just four ints.

Thanks to Andreas Schneider for pointing out the issue.

KJob::result() is not emitted when job is killed quietly which prevents
Session from scheduling the next job until the killed job is destroyed.
This leads to responses being delivered to a wrong job when the job is
killed.

BUG: 364005
CCMAIL: faure@kde.org

Laurent has fixed modifying search parameters in Akonadi server,
let's have a test to make sure it does not break again. Just by
enabling this test I already discovered and fixed two issues in
PersistentSearchAttribute.

The parser ignored the last keyword, which usually is RECURISVE.
By ignoring the keyword, the attribute would claim the search is
not recursive even though it is.

We only set 'remote' to true when the REMOTE keyword is present, we
don't however set it to false, when the keyword is no present, meaning
that the attribute claimed that the search was remote even though
it wasn't.

Use ${QtSql_PRIVATE_INCLUDE_DIRS} to include the private headers
directly from current Qt install instead of carrying a local copy.

The GidTest needs to retrieve item payload from the resource, so we
need the resources to be online for that, otherwise the tests timeouts.

This test needs the resources to be online for remote search test.

Because why not

C++11 is now provided by ECM, ASAN is set in CI. All the Qt definitions
come from ECM now.

The CI only shows debug output from the test itself, but that is
often not enough to find out what went wrong when the test fails.
This enabled full debug output for everything inside the testrunner
environment.

- I already found what I wanted to know
- Putting the message() in this particular place made it be printed
  like 20 times.

This reverts commit 84326213.

I'm debugging why this works on the CI when it seems it shouldn't...

I wasn't able to reproduce locally, but on CI we were hitting the
newly added assert when receiving response after the job said it
does not expect any more response.

The server will send either one FetchTags or one DeleteTag response
followed by ModifyTags response.

First debug, then assert, so we know more about why we asserted.

FIXED-IN: 5.2.2
BUG: 358696

During DB initialization when multiple resources try to synchronize
and insert first item, the mimetypes, parttypes and other similar
tables are empty and the entries need to be created. This presents
a race condition when multiple threads try to create the new entry
at the same time - one of them is succesfull, the others usually
abort, which leads to the resource failing the synchronization.

retrieveByNameOrCreate() will try to retrieve the item from cache
or DB first. If it does not get any result it tries to acquire a
lock. If the thread gets a lock it inserts the new entry into DB
and cache. Otherwise the thread just waits for the lock (i.e. until
the thread that acquired the lock inserts the new entity) and then
retrieves the entity from the cache.

This isn't really a common situation, which would happen during normal
usage of Akonadi. We however see it quite often during unit-test
initialization when all three Knut resources start pushing their
data into Akonadi at the same time and trigger this race condition.

This affects mostly CollectionSync, which would emit result() signal
while a CommitTransaction subjob was still running. This caused the
response to the CommitTransaction to be delivered to subsequent job
started after the CollectionSync and was causing all kinds of havoc
(like CollectionFetchJob emitting result() twice - once because of
the CommitTransaction response not addressed to it and second time
once the actual CFJ response arrived) in both clients and resources.

The CollectionCopyJob was expecting CreateCollection response instead
of CopyCollection, causing it to trigger warning every time. Luckily
no harm done there, since the job does not expect the Response to
contain any data and only takes it as an indicator of result.