Add root storage

[lok52]

Closes #62

Add separate root storage to relayer similar to roots mapping in ZkBobPool contract.
It allows more strict validation of users' transactions on relayer side reducing the possibility to drain relayer sending reverting transactions.
Logic flow is similar to nullifierSet, but root storage is built using HSET redis command, maintaining a mapping from a pool index to a corresponding root.

Applications states:

• Initialization: on startup relayer fetches all transactions with corresponding calldata and starts building the storage from ground up.
  

  zeropool-relayer/zp-relayer/pool.ts

  Lines 207 to 212 in 3e5fb03

  	// Save root in confirmed state
  	const root = this.state.getMerkleRoot()
  	await this.state.roots.add({
  	[newPoolIndex]: root,
  	})
  	}

• Relayer received a transaction:

1. Extract delta index used in proof construction and lookup a root by this index in confirmed and optimistic storages. If root is not found in any of storages then tx is invalid. If root is found but it is not equal to the root used in proof construction (we get it from public proof inputs) then tx is invalid.
   

   zeropool-relayer/zp-relayer/validateTx.ts

   Line 213 in 3e5fb03

   await checkAssertion(() => checkRoot(delta.transferIndex, root, pool.state.roots, pool.optimisticState.roots))

2. Save the root in optimistic root storage.
3. Check if tx is mined:
   3.1. Mined: remove root from optimistic storage and include it into confirmed storage.
   

   zeropool-relayer/zp-relayer/workers/sentTxWorker.ts

   Lines 88 to 93 in 3e5fb03

   	// Add root to confirmed state and remove from optimistic one
   	const poolIndex = ((commitIndex + 1) * OUTPLUSONE).toString(10)
   	logger.info('Adding root %s %s to PS', poolIndex, root)
   	await pool.state.roots.add({ [poolIndex]: root })
   	logger.info('Removing root %s %s from OS', poolIndex, root)
   	await pool.optimisticState.roots.remove([poolIndex])

   
   3.2: Reverted: delete whole optimistic root storage
   

   zeropool-relayer/zp-relayer/workers/sentTxWorker.ts

   Lines 120 to 121 in 3e5fb03

   	logger.info('Clearing optimistic roots...')
   	await pool.optimisticState.roots.clear()

[r0wdy1]

Could you add a test for both good and bad cases?
This change seems to be rather difficult to test manually on staging environment, so it's better to have some test coverage

[lok52]

Could you add a test for both good and bad cases? This change seems to be rather difficult to test manually on staging environment, so it's better to have some test coverage

It is rather hard to implement such e2e test where multiple transactions will be in optimistic state and then make the first one fail. We need to run a local node in no-mining mode and manually send requests to mine blocks at specific points in time. I will try to make it, but it does not look straightforward for now.

[r0wdy1]

looks good, although further testing is required

[akolotov]

@LyzeOfKiel please fix the merge conflict

[lok52]

Will fix conflicts after #78 will be merged in this branch

[akolotov]

Will fix conflicts after #78 will be merged in this branch

Could we merge this PR first and make a rebase for #78 so it will be targeted to devel?