Forced exit support

[lok52]

Closes #201

Changes:

1. Create EventWatcher abstraction and refactor direct-deposit watcher
2. Use EventWatcher for forced exits:
   2.1. New events are submitted to the forced-exit queue with a delay specified in the event
   2.2. After the delay relayer confirms that user indeed finalised the exit. If not, then nullifier is removed from local storage

[r0wdy1]

lgtm

[EvgenKor]

Suggested change

	jobLogger.info('User successfully finalized forced exit', { nullifier })
	jobLogger.info('Forced exit was outdated', { nullifier })

It's not pretty correct message. User also may cancel FE during 10-min buffer time interval in forced exit queue

[EvgenKor]

I'm not sure but it's seems the relayer will not restore watcher workers for active forced exits in case of restarting or failure. In that case the associated nullifiers remain in confirmed state and user cannot execute transaction after FE time interval will become expired. Could you please confirm or deny it?

[EvgenKor]

It seems that your solution doesn't include complete forced exit logic.

1. You doesn't make distinguish between used nullifiers and committed ones for forced exit. It would be better to keep such nullifiers separately to make possible returns relevant errors (currently doublespend error will occurred if user will try to transact during forced exit timeframe)
2. You cannot block user transactions efficiently while you pull events with some time interval. Imagine I sent forced exit commit transaction. Relayer will know about it within 10 minutes. During that time I can send regular transaction to the relayer and it will not blocked. And my forced exit will become invalid (because the nullifier will used). Such behaviour seems not valid. I think you should check committedForcedExits[nullifier] during transaction validation. But to make it correctly you also should take in mind when associated forced exit time window will close (because committedForcedExits[nullifier] won't removed before forced exit will become canceled by user)
3. It would be better if you can check if user send transaction from the dead account during the transaction validation. It's needed to produce relevant error (for now the error message is doublespend detected in that case). To do that you need to check nullifier value (poolContract.nullifiers[nullifier]). The account considered to be dead if the nullifier value match pattern 0xdeaddeaddeaddeaddeaddeaddeaddeaddeaddeaddeaddead0000000000000000

[EvgenKor]

We have decided after the discussion the relayer behaviour is acceptable for the edge cases described above

[k1rill-fedoseev]

lgtm