Method needed to stop block synchronization at specified round or blockheight

[Isabello]

In order to produce clean snapshots that can be verified a method to stop block chain synchronization is needed. Under current state block height will continue to happily sync and get blocks even after verification is complete. While this is positive for nodes running the chain, its less than optimal for nodes running for the purpose of securing and validating snapshots.

A sub function of verifyOnLoad is needed to remedy this. A new config.json entry will be required and could be either blockHeight = ### or roundHeight = ###

The loader would need to be modified to check one of these two new entries and cease processing upon recieving the specified block at the end of the round or at the block height. This way there would be no dirty records uncommited or pulled from blocks past that point. Clean backups could be taken and verified from the node state since there should be no inconsistency in records produced.

[fix]

Actually the real issue is to be able to have a clean database whatever happens. The code is not organised clearly to do so. Otherwise the only option is to rebuild the mem_* tables from ground up at each restart.

[Isabello]

So cycling the database at all can cause issues ?

[fix]

well the thing is that there is NO 100% sure way to actually check if the database is clean, except rebuild the mem_* from ground up and compare the results.

The only thing we can do is try to trigger a backup WHEN we think this should be ok (after flushing the mem_round for instance).

This is something to be thought in long term. To give you an idea, Bitcoin has created SPV (Simplified Payment Verification, https://en.bitcoin.it/wiki/Thin_Client_Security#Simplified_Payment_Verification_.28SPV.29_Clients), in order to perform on blockchain "100%" (ie provided no sybil or partitionning attack) sure transaction proof and not rely on internal states of bitcoin peers (which can be tampered with or simply wrong). We should think about something similar, like a STV (Simplified Transaction Verification), maybe to be included in white paper. This STV could be applied regularly on the database, cherry picking "interesting transactions" to validate its internal state. It can be applied also on "sensitive" (high amount, unknown address...) transactions validation.

cc @karmacoma @MaxKK

[fix]

After quite a few tests, it sounds that the best place to stop is here:
https://github.com/LiskHQ/lisk/blob/7c8aedd82bf09449389a75a3dc7e21176ba98cd9/modules/delegates.js#L507

Never had to rebuild when i triggered some process exit here.