Handle blockchain reorg

[piohei]

We should be able to handle reorg that will happen on chain.
For indexer that means:

• cleanup events in database that were removed from chain
• catchup on new events/logs
• fix accounts authenticators state (stored in database) - this can be non-trivial
  For other services:
• maybe nonce will need to be updated
• some proofs may become invalid

[alessandromazza98]

To add even more context here, there is a downstream issue with the gateway as well, in particular for the is-valid-root endpoint. The reason is that the gateway currently uses a cache to store recent valid roots. So there could be a scenario like this:

• root A is added and is also added to cache
• then a reorg happens and root A gets reorged out, so it's no longer valid in the contracts due to this reorg
• immediately after the reorg, a is-valid-root request is sent to the gateway with root A as input. The gateway returns true due to root A being in the moka cache, but this is incorrect

To make it work more correctly we can:

a. remove the cache entirely and always do a rpc call to the WorldIdRegistry contract and rely on it.
b. rely on the indexer instead, but this of course requires the indexer to be reorg-aware as well. And of course we're still doing a http request so I'm not even sure this would save time compared to a classic rpc call to the contract.
c. use a short TTL on the cache to ensure that this scenario becomes almost impossible (still a tradeoff)

[piohei]

as and idea for the indexer - hard part there is to update accounts table as it stores state of current authenticators pub keys. Maybe instead of storing it in database we could just query contract (querying should be gas free) for the account public keys. We can easily cache them if needed.