A simple Evolution run and move between all views means creation of
more than 100 GSettings objects, with only a bit more than 10 schemas.
Reusing the objects should have a positive impact on a performance too.
Apparently the migration logic was more complex than it needed to be.
The old numeric key was already synced to the EMailReplyStyle enum in
the source code. Dunno where I got the idea it wasn't.
Just more evidence numeric enum keys are bad.
My previous patch didn't go far enough to repair an already-corrupted
"show-headers" key. Need to actually reset it to its default value if
the "headers" key is empty.
Replaces the "headers" key. Whereas "headers" is an array of XML
blobs, the "show-headers" key is an array of string/boolean pairs.
Also update the appropriate places to get/set the new key.
Mainly to avoid accessing GSettings directly from EMailBrowser.
Also add a "browser-close-on-reply-policy" GSettings key that replaces
"prompt-on-reply-close-browser", the difference being the new key uses
an enum definition compatible with EAutomaticActionPolicy instead of a
free-form string value.
And finally add an ESettingsMailBrowser class to glue things together.
This class is different from the others in this module. Its purpose
is to transfer values from deprecated GSettings keys to the preferred
keys on startup, and keep them synchronized at all times for backward
compatibility.
Initial deprecated keys being handled are:
"week-start-day" (org.gnome.evolution.calendar)
"working-days" (org.gnome.evolution.calendar)
