Deleting, what should by now be a redundant, "if processing peers is empty" check in converger_1/server.h 'on_sync_timeout'. The being-deleted code is, probably, a legacy mechanism from the design days when the server-side-syncing was done periodically as opposed to, currently deployed, 'on demand' scheduling -- triggered by the newly arriving peer reports, etc.)
Adding an additional 'todo' (efficiency related) for using the emplace-hint during map-population of the remaining complexities when resuming a job from the saved convergence state.
Better hinting w.r.t. C++11 map-addition (as well as 'todo' preparation for C++11 improvements w.r.t. 'emplace' calls) in range_utils.h ... the current implementation may not be 100% optimized w.r.t. C++11 hinting of maps, but better do it now rather than later (i.e. in anticipation for the, invariably, upcoming updates in the stdlibc++ implementation).

In a similar spirit, in the combos_builder, have added a hint when individual combos are introduced to the map -- to make the process faster during the 'build'-ing of the combinatorial complexities.
Fixed, regression, bug: could (albeit with a low probability of occurance) falsely assert 'better_find_since_last_recentered_sync == false' in 'save_convergence_state' because now saving of the convergence state is essentially a delayed action which may be triggered between the new peer_report arriving and the next on_sync_timeout taking place...

Now have subsequentnly refactored the code to use a newly-added 'dont_delay_saving_convergence_state' flag (if true then on_sync_timeout should issue immediate/direct call, otherwise a delayed timeout) this is mainly due to the following considerations:

1) The act of saving convergence state should, ideally, happen only when 'on_sync_timeout' has synchronised all of the state-related data... (otherwise some sanity-assuring asserts may cause false negatives, such as testing for all of the visited places not to be contained in the remaining_complexities during startup/loading of the saved state, etc.). Besides it is really a trait of the whole design/simplicity -- there is only one authoritative state and such is done in one normative point -- namely the on_sync_timeout, and it is the delayed action of the saving of the convergence state that is an afterthought/reaction of not slowing the system down by saving the thing on every state change whilst at the same time not waiting for the next zoom-in taking place in order to save the last batch of the great number of visited places.

2) If not implementing via the aforementined flag variable (but simply by returning early in 'save_convergerce_state' if the 'on_sync_timeout' timer is still pending) then it could be the case that saving of the convergence state would be delayed indefinitely (thereby not saving the huge amount of calculations and multiple zooming-in stages) -- because the 'save_convgergence_state' timer may fire after the 'new peer report' arrives but before the scheduled-in-response 'on_sync_timeout' takes place meaning that (due to the first point of consideration) the 'save_convergerce_state' will be postponed until the next timeout (e.g. in the next hour) ... if such a situation takes place multitude of times (albeit in extremely unlikely, yet still in a realm of possibility, scenario) then a lot of data may not be saved for a long time indeed.

Still untested though, so expect some bugs... indubitably.
Added a howto on printing certificate's fingerprint.