[Evolution-hackers] more camel api changes

[Not Zed <notzed ximian com>]

Not so much api.

Anyway, for all you evolution provider writers (uh, connector i guess),
these calls:

 - camel_store:get_folder
 - camel_store:get_folder_info

Are no longer serialised using the CamelStore->priv->folder_lock.

get_folder is already serialised, but only per-folder, so if you do any
store-wide stuff in your implementation it may need tweaking.  In imap
we serialise things using connect_lock anyway, so it isn't an issue.  In
local folders we don't need to serialise (although this could lead to
thrashing if you open a lot of folders in parallel - or perhaps improved
startup time due to parallelism).

get_folder_info doesn't really need to be serialised, afaict, except
perhaps to reducing thrashing again.

This is to fix a deadlock with offline mode, i hope.  God knows what
other bugs i've just exposed, so keep an eye out if you use imap.
Startup is probably going to show any issues that exist.

In the future I want to look at removing folder_lock probably entirely,
it isn't really needed I think, there are other serialisation mechanisms
already in place or easy to add.

In the far future the same for the global CamelFolder lock, but thats
less important right now.  But needed to get any better performance out
of imap, if a non-synchronous driver is ever written.

I also want to look at just moving camel-disco-store stuff into
camel-store (or service) i.e. just store the folder state the same as
the service state.  This should reduce the possibility of state
inconsistencies and make the code a little bit simpler, it'll just be up
to implementations to choose their implementation based on the current
online state.  CamelDiscoStore is pretty light-weight, and everthing
else in imap is re-usable if its functionality is merged into another
class.

 !Z