We need to have sessionID available on server side so that we can correctly
resolve Collection referencing based on session when accepting/discarding
notification.

Use a QThreadPool to run NotificationSubcriber::notify() for multiple
instances in parallel. This might provide a small speed up with large
amount of subscribers, but nothing big. It will be more visible once
we start sending notification payloads.

Makes debugging easier. Fallbacks to this pointer-as-int.

It sometimes happened that the server managed to deliver Hello response
before we could connect to the commandReceived() signal. Now we first
connect to the signal and then ask Connection to establish connection
to the server.

Wait until client identify itself before sending it notifications.

Different entity types have different data, so sharing a single
structure to describe changes in all entities is limiting. Having
a single structure made sense when we only had Items and Collections
which share most of the attributes and it was also easier to expose
this via DBus.

Now we are no longer limited by DBus so we can afford having a
different Protocol command for each notification type. This will be
most important when we introduce SubscriberChangeNotification, as
subscriber changes would otherwise be hard to map onto the legacy
ChangeNotification and is also the first step towards Notification
Payloads.

NotificationManager now lives in separete thread. It creates
NotificationSubscriber object for each new connection on NotificationServer.
Each connection does not have its own thread as in case of Connection,
because the communication there is minimal and we don't mind if the
NotificationManager thread gets blocked for a short moment.

Each Subscriber keeps state of the subscription. When a notification is
delivered to NotificationManager, it will pass them to all subscribers
which will then decide whether they accept the notification and eventually
send it to subscribed client.

Currently this breaks notification and subscriber debugging because we
completely removed the DBus introspection. The plan is to introduce a
subscription change notification (a type of Protocol::ChangeNotification)
that clients like AkonadiConsole could subscribe to to get information about
new or removed subscribers and their subscription state.

This creates so called CommandServer and NotificationServer, both
QLocalServer listening using named pipes (this is a move away from
a socket file to avoid having multiple files).

Each new connection on CommandServer makes AkonadiServer to instantiate
new Connection object as normally. For NotificationServer each new
connection is handed over to NotificationManager, which will deal with
it.

Those will be used to control change notifications subscriptions through the
protocol instead of DBus.

When copying or moving large batch of items they all have to
go through ItemRetriever first to make sure all payload parts
are locally cached. This can take a lot of time, so to make
the operation seem more responsive, we don't wait for
ItemRetriever to finish retrieval for all the items, but
processes every batch as soon as the ItemRetriever reports
it as finished.

Fix a loop in ItemRetriever when we have more parts available
than requested as well as when only some requested parts need
to be retrieved.

Make ItemRetriever interactive by emitting a signal with list
of already retrieved items and using QEventLoop to block inside
ItemRetriever::exec() instead of blocking on a QWaitCondition
inside ItemRetrievalManager.

Add a unit-test with several different scenarios.

To be able to use ItemCreateJob with merging for handling FetchItems
task result, we must have parent Collection, so always fetch it, even
if user did not ask for it.

We now treat the field as QStringList by default, falling back to
the new behaviour if the list has only one value.

Tread the default value as QString, not QStringList. The string value
is stored in QVariant and can then be converted from boolean, number
via QVariant::to*() methods. This does not work if the value in QVariant
is stored as QStringList.

This fixes the isScopeLocal() hack for Indexing Agent in FetchHelper.

The server guarantees that a single batch of FetchItems task will never
have more than 100 Items, so we will have at most 100 ItemModifyJobs
within a transaction, which should be OK performance-wise.

Properly handle cases when one (or more) Items in the batch
already have the requested payload parts and deal better with
null "LEFT JOIN PartTable" results due to the Part being an
attribute, not a payload.

This introduced a new DBus call on Server to get path to its
config path. This is useful when one wants to figure out the
config path of a Server running via testrunner, i.e. having
XDG_CONFIG_DIRS randomly set in /tmp.

Secondly it introduced an API in XdgBaseDirs which allows
overriding the config dir path - this is useful when you
want to connect to a server which is running with different
XDG_CONFIG_DIRS than yours, e.g. in AkonadiConsole.