Architecture improvement: isolate DB access to the Sentry

[Ivshti]

possibly replaces the need of #31

The proposal is to change the architecture in the following way:

• The Sentry is the only component that has a connection to the database
• The worker ticks are refactored into pure, testable functions
• The worker executable (bin/validatorWorker) would retrieve the latest messages from the Sentry, the latest event aggregates, and produce new message (either NewState, ApproveState/InvalidNewState) and submit it back to the Sentry (actually, propagates the messages to everyone)

There are a bunch of benefits:

• Replaces DB abstraction #31 and allows us to swap out the DB more easily
• Allows easier testability by testing the follower/leader tick pure functions
• Security: before producing a new state, we'd always validate the previous one and whether we signed it; DB tampering becomes less of an issue

This, however, also requires dropping the Watcher. Instead, that functionality would be moved to the adapter. When a channel is submitted, the adapter will check if it's admissible. For Ethereum, this would mean that the channel is submitted on-chain. This also has the advantage of immediate feedback.

In order to still preserve the ability for end-users to submit channels without waiting for them to be submitted on-chain, we can implement a submission API in the Market or more appropriately the Relayer that would try to submit the channel to the validator, after it's on-chain.

Another possible issue is that there's no API to submit the full tree in the Sentry. However, we can introduce an Accounting message type to do the same. In order to optimize this for storage/performance in the future, we can purge the tree for the older states.

---

TODO:

• adapter.sign should ensure replay protection itself; see Heartbeat - getSignableStateRoot does this exact thing
• REFACTOR: validator msgs: sequential ID?
• REFACTOR: /last-approved/ method on the sentry AND tests
• REFACTOR: newState: should only use balances
• REFACTOR: drop isValidValidatorFees; this check is pointless, since ultimately we're signing and enforcing OUTPACE/health on balancesAfterFees; so if you want to deceive the follower, you can always forge a preimage of balancesAfterFees which will pass the check; in other words, nothing really depends on the balances before fees (in NewState/ApproveState), so no point in enforcing it
• API: should we wrap validator messages in msg? we lose from and received: decision: yes, we lose nothing from having that
• sentry interface, in place of the propagation lib
• drop nothingNew - ticks would be ran every time
• drop stateTree
• make everything work
• accounting: { lastEvAggr, balancesBeforeFees, balances }
• InvalidNewState should be emitted only once; so ticks should happen only if there is no OUR msg with that stateRoot
• test: we only respond to a new NewState once
• read through the doc/pseudocode and see if we missed anything
• decide on purging/cleanup logic

---

and some tests improvement in a separate PR:

• test: DRY, async/await
• test: no NewStates are being produced when we just trigger the tick
• test: invalid transition
• test: propagation works

[samparsky]

Use async / await syntax #77 for the refactoring

[Ivshti]

done with the merge of #88