Semi-sized commit (mainly to do with the netcpu/server functionality) -- include bug fixes, refactoring and quality assurances.

BUG-FIX:

(*) saving of the convergence state "immediately" when the tasks are being reordered (was not working before because of a combination when 'dont wait' flag was not set (the "on_sync_timeout" therefore did not bother to save directly) and the "save_convergence_state" was not saving the state because the "on_sync_timeout" timer was still showing as pending (due to invocation of the whole thing from the destructor rather than from a timer's callback and so the "pending" status was still 'true').

REFACTORING:

(*) Rethinking the ever-incrementing trait of the 'task_id' variable... In it's technical essence there's nothing wrong with it (i.e. 64bit u_ints are not going to be saturated for the whole of server's lifetime -- in the context of this infrastructure that is). However, the thing is -- it's rather difficult to visually manage very long numbers (i.e. > 5 digits) and so a certain wraparound still should take place (on second/third/or-whichever-one-it-is-by-now thought :-) Basically having a 'wheel' of the numbers (eventually such a wheel "wraps around", but the requiremnt being that there should be enough 'free' gap between currently-issued and the oldest/previous number so that the same task id shall not be issued within a reasonably short period of time, even if a given task is created and then deleted right away, and no confusion should arise out of the recycling of the same task id numbers... kinda similar to the PID recycling in Unix systems... at least in the spirit of things :-)

(*) Re-engineering, a bit, the sorting order of completed tasks -- now ought to be ordered by their creation time.

(*) Minor improvement of not-writing to disk on every completed task load during server's startup.

QUALITY-ASSURANCES:

(*) Minor addition to the quality-assurance of the written files (throws more often on failier).

(*) Minor addition to the quality-assurance in the scoped membership iterator object (not allowing self to be assined to self -- otherwise newly-inserted element in things like sets and maps may actually be the existing element and such will be erased in the scoped iterator assignment... generally, and currently asserted-for spirit of simplification in one's design would suggest that the aforementioned "self-assingment" ought not to take place... ideally and yet indubitably :-) :-)

(*) More pedantic use of iterators in a list (not doing ::std::prev(begin()))

(*) Very light change when counting steps whilst moving a task down the queue of pending tasks... basically for the sake of pedantic correctness of signed integer being undefined if an overflow occurs (albeit in this case it is pretty much not going to happen)... just making a compiler happy and myself a little happier :-)

(*) A convenience-related, and a quick one at that, hack -- introducing additional validation of task directories during the netcpu-server's startup. Validation aims at detecting any, accidentally, remaining incomplete task directories (i.e. missing message files, etc) due to the program's crash.

The previous code revisions are, indeed, without any danger of introducing 'false positives' --  where the convergernce would proceed whilst using a corrput file(s)... this is because each of the written/composed file is already 'hard relinked' from a temporary to real one only *after* all of its contents have been written out (i.e. atomicity is in effect). Consequently this hack is really about extra convenience -- when restarting the server the aforementioned issues would be brough to sysadmin's attenion immediately, as opposed to moments when a given task is activated or is involved in 'tasks_list/task_info' query...

Of course, there are cases when/if the whole box can come down crashing (e.g. abbrupt power loss) -- but such a problem is capable of affecting the whole of the system's files, not just NetCPU et. al. and so is a matter for another consideration (e.g. a todo considering flushing of data to disk, writing sha checksums, or simply relying on the overall system's ability to implement filesystem integrity checks after restarting from a crash, etc.) ...

... in the meantime are taking care of those issues with relate closer to the program-specific behaviour (e.g. sigkill, or crashing out of the app) and leaving system-wide issues to be handled by other, system-wide as well as hardware, considerations (e.g. ZFS is making progress there anyways -- from http://en.wikipedia.org/wiki/ZFS#Data_integrity )