The codepaths related to the session setup are currently very error prone, since they use a lot of async code, but don't protect the internal state of the objects sufficiently. This can be solved by moving all async code and the related state to dedicated job objects.

In particular are synchronous dialogs invoked, meaning almost arbitrary callbacks can occur if the user forgets a dialog and then closes it, at which point the object may already be in a completely different state.

Some examples are:
* SessionPrivate::handleSslError invokes a dialog at the end of a process started by SessionPrivate::startSsl, while the process depends on the internal state of SessionThread and startSsl may be invoked multiple times. This means SessoinThread::sslErrorHandlerResponse can be invoked at any time, even if a second run of startSsl already succeeded and already established a secure connection.

* SessionPool::onPasswordRequestDone can be invoked again due to a stale password dialog getting completed. At this stage assumptions about the internal state (such as m_pendingInitialSession being set in the ReconnectNeeded) are likely to not be true anymore.

The bottom line is, either protect async codepaths from being entered multiple times, or move the state to separate job objects, so the code can safely be run multiple times in parallel.

I'm pretty sure this would fix at least some of the crashes we have in the imap resource.

Reproducible: Always