There still was an issue with stopping IDLE, the code could have run IDLE
in the preparation, like selecting the right folder, when it received
a request to stop IDLE and start other command. As the preparation was
not distinguished properly two commands could interleave and cause issues.
When in it, the IDLE stop had been done to stop it gracefully, instead
of disconnect the connection when in the middle of some command. It
should make things quicker (reconnect is slow), especially when the connection
is not stale.

It seems the imapx_disconnect() can be called from multiple threads,
eventually causing use-after-free on is->priv->cinfo. Adding a lock
around the private cinfo structure should avoid the crash.

Reported at: https://bugzilla.redhat.com/show_bug.cgi?id=1293028

This could cause confusing runtime warnings when trying to handle
IDLE marks for mailboxes, when two threads were stopping IDLE call
on one connection.

There still had been some issues with IDLE handling, sometimes it
would look like the command is not running, but it was initiated
anyway, other time the DONE command had been issued multiple times
and so on. This change makes the handling of IDLE more reliable.

Do not cache default connectable, rather always create it, because
the object might not be thread safe.

My previous changes caused IDLE not to be stopped gracefully, which
could cause several issues and side effects, for example if ever seen
an error "Stream has outstanding operation" in UI, then it was one
of the issues being caused by it.

Sometimes, with a good thread interleaving, one connection could be
used by multiple threads at once, this resulted in runtime warnings like:
> Starting command ... while still processing ...
which is a safety check for these cases. This change makes sure that
the connections are reserved for one thread only.

This is a function introduced in libical 2.0.0, which influences
the way libical timezones are returned. The interoperability mode
means to turn exact timezones off, thus they are returned with
RRULE, intead of "expanded".

This is to avoid processing of IDLE responses for changes made by itself
and have running IDLE commands multiple times on one folder. Both can
cause misbehaviour in the UI.

When, for whatever reason, some 3rd-party plugin with its own private
directory wasn't installed, its private directory was moved to trash,
but never recovered, even when it was installed again.

The function could be called from within camel_pop3_folder_delete_old(),
which already holds the lock, thus the later attempt leads to a deadlock.
Reported by cooly.

While the session is supposed to be always there, it can be gone
in case of the application close, thus check for this too.

The ':' is not allowed in the file name, use '!' instead.