The CalDAV tweaks had been updated only after successful connect to the server
since the changes with ECalMetaBackend, but the backend's user-email property
did use this tweak information, which caused the backend report no user-email
address, because this information is precached shortly after the backend
is opened (but not yet connected).

This had been reported downstream at:
https://bugzilla.redhat.com/show_bug.cgi?id=1515776

This way the command can use ranges, instead of name each UID separately,
thus can eventually make the command shorter.

Follow up change for a downstream report:
https://bugzilla.redhat.com/show_bug.cgi?id=1530569

The previous code meant that whenever a UID COPY/MOVE had been issued
a SELECT to the destination folder and then (eventually back) to the source
folder was done as well, even when it was not needed. Doing the destination
folder SELECT only when needed speeds up message filtering by skipping
unnecessary SELECT commands.

It could happen, in some situations, that an ESource could be freed
in a dedicated thread, while it had been in use in an idle callback.
As it held a corresponding mutex, the crash happened in the finalize()
function, when it had been tried to free that locked mutex.

The change removes obsolete members from the private structure of
the ESource and references itself for the idle callbacks. Even it
avoids early free (and idle callback cancellation in the dispose()),
it will make sure that the ESource will not disappear while the idle
callback is running, the same as it'll avoid some other races around
this situation.

It had been reported downstream at:
https://bugzilla.redhat.com/show_bug.cgi?id=1533442

Not a usual thing, it might happen when the background directory changes
without Camel's intervention, but still valid.

It can happen that the LDAP backend is disconnected from the server
while it's processing some operation, in which case the check for non-NULL
ldap handle could come after this had been passed to an LDAP function,
which can eventually have an assertion on non-NULL ldap handle to be
passed in. This change handles the NULL ldap handle case gracefully.

This had been reported downstream at:
https://bugzilla.redhat.com/show_bug.cgi?id=1530569

This reverts commit 71c8d688.

Book/calendar part didn't work properly. Its workflow was:
a) try with empty credentials => fail with CREDENTIALS_REQUIRED response
b) source registry noticed it and asked for credentials, but
   the Google provider returned no credentials when reading them
   from the store (due to expired access token)
c) left the source wait for credentials until they are provided
   by some GUI application
d) in case of Evolution it could show either "Unknown error" or
   "Credentials required" error in the UI, instead of refreshing
   the token.

This changes the b) in a way that when the lookup fails, but it still
can read credentials, only the token is expired, then it'll refresh it
and save, which will connect the book/calendar without a need for a GUI
application with running credentials prompter.

It had been finishing with no error set, but failure, when no credentials
had been provided. This could lead to "Unknown error" errors shown in
the UI for Google calendars/books with stored expired access tokens.

With respect of ESoupAuthBearer (used mainly with CalDAV), the missing
implementation of the e_soup_auth_bearer_update() could cause repeated
requests with the invalid access token, which had been eventually
aborted after many tries by libsoup with a runtime warning:
"SoupMessage <pointer> stuck in infinite loop?"
The change makes the access token expired in such case, which stops
the cycle early and doesn't increase the error counter on the server.

The GData authorizers didn't consider expiration time at all.

Instead of reporting rejected credentials when the server returned
such code during SASL authentication cycle the code returned error
instead, which didn't give a chance to prompt for the credentials.

When a CamelOfflineStore had been going online, the other calls inside
the function could connect the store, but the function used the connection
state from the beginning of the function (stored in a variable), which
means it could be using obsolete information. Another thing had been that
the disconnect doesn't make sense when the store is going online and
when it is either disconnecting or disconnected already.

This reverts commit 51c757bf.