• 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 :)