Synclet scheduler should be unified

[mdz]

Currently, initial scheduling is done in lsyncmanager.scheduleRun(), but then this is modified in lsyncmanager.executeSynclet() to back off based on how much new/changed data there is ("tolerance") or whether another synclet is running (delays by 10 seconds), with the result that it's hard to follow the logic to tell when something will run (and the log message lies).

It would be good to combine this logic into one function, which would determine the next run time and do appropriate logging.

[mdz]

The complexity here is making it hard for me to see why things like this can happen:

14 Mar 06:50:46 - verbose: scheduling twitter-mentions to run immediately (missed)
14 Mar 06:50:46 - verbose: scheduling twitter-mentions to run immediately (missed)
14 Mar 06:50:47 - verbose: tolerance now at 4 synclet mentions for twitter
14 Mar 06:50:47 - verbose: scheduling twitter-mentions (freq 600) to run in 596.81s
14 Mar 06:50:47 - verbose: tolerance now at 3 synclet mentions for twitter
14 Mar 06:50:47 - verbose: scheduling twitter-mentions (freq 600) to run in 622.613s
14 Mar 07:00:44 - verbose: tolerance now at 2 synclet mentions for twitter
14 Mar 07:00:44 - verbose: scheduling twitter-mentions (freq 600) to run in 458.268s
14 Mar 07:01:09 - verbose: tolerance now at 1 synclet mentions for twitter    <--- this is much less than 458 seconds later!
14 Mar 07:01:09 - verbose: scheduling twitter-mentions (freq 600) to run in 463.916s
14 Mar 07:08:22 - verbose: tolerance now at 0 synclet mentions for twitter
14 Mar 07:08:22 - verbose: scheduling twitter-mentions (freq 600) to run in 720.619s
14 Mar 07:08:53 - verbose: delaying mentions
14 Mar 07:09:03 - verbose: delaying mentions
14 Mar 07:09:13 - verbose: delaying mentions
14 Mar 07:09:23 - verbose: delaying mentions
14 Mar 07:09:33 - verbose: delaying mentions
14 Mar 07:09:43 - verbose: delaying mentions
14 Mar 07:09:53 - verbose: delaying mentions

[mdz]

FYI it looks like this code has been refactored quite a bit in 3c5e3c8 (ijod branch)so we should probably not