avoid walking ledgers when possible
handles missing nodes properly when walking state map
makes "fail_hard" true by default

fail_hard is a flag that controls the behavior when getting a retryable error at submit time.
when the flag is not set retriable errors are still queued on the local instance, that will keep trying to submit it in the background.
This can be confusing for the caller of an API as normally an error
avoid holding transactions

expire old transactions awaiting to be applied
transactions were only purged when getting a validated ledger but this can take a really long time if the instance has a lot of data to download.
this was in turn causing a lot of transactions to be held and re-applied

ban transactions that fail
transactions that have no way of succeeding are marked as failed and not applied.
Bad transactions can be injected (if they were failing with a retriable error at submit time for example),
this allows to avoid keeping applying them (until the transaction gets expired frmo the local tx set).
Merge pull request #175 from MonsieurNicolas/better_sync

Performance improvement when catching up

Reviewed-by: jedmccaleb