Summary:
- it turns out that the whole job gets terminated
- after changing FakeSession to delay reconnect like Session,
the unittest actually makes more sense (no more comment about signal not
received because emitted from the constructor)
- call socketDisconnected like Session ends up doing

The main point was to debug a crash I was having in TransactionSequence
when killing subjobs in rollback(). The take away is that disconnecting
from slotResult is a horrible idea, it means mCurrentSubJob stays
dangling and later lostConnection() crashes. Disconnecting is currently
only done for non-running jobs, but too much code sharing brought me into
that bug :)

Reviewers: dvratil

Reviewed By: dvratil

Subscribers: kde-pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D19742