storage: add index for efficient fetching of events emitted by a specific contract

[ptrus]

Part of: #804

This will enable efficient querying of all transfers of a specific ERC20 token. This is needed for the Transfer tab in the tokens details page (https://explorer.oasis.io/mainnet/sapphire/token/0x6665a6Cae3F52959f0f653E3D04270D54e6f13d8). See issue description for some more details.

Creating the index on the live instance might take some time, so ideally, the index is created CONCURENTLY sometime before deployment to prevent the migration from blocking the deployment.

Note: This doesn't resolve the inefficient accounts-related query, which is also mentioned in the issue. That one will require a separate (likely more significant) change.

TODO:

• add a test case for the newly supported query
• I applied the index on labs staging mainnet deployment and confirmed the queries are now fast, e.g. (https://nexus.oasis.io/v1/sapphire/events?offset=0&limit=10&type=evm.log&evm_log_signature=ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef&contract_events=0x6665a6Cae3F52959f0f653E3D04270D54e6f13d8)
• Also applied the index to labs production mainnet
• prod testnet
• staging testnet

[pro-wh]

index looks ok, so I'll just approve it. but this won't be the last we hear from this category of problems.

for #804, I think the original intention of the db design was to get a good-enough scan of the events_related_accounts index and then filter specifically token transfers emitted by the contract. but from what I'm hearing, the events_related_accounts index is not viable, I'm guessing due to it not being sorted by round. we need to do something about that, which can be separate from this PR, but still ugh

[ptrus]

events_related_accounts index is not viable, I'm guessing due to it not being sorted by round

Yeah exactly. It works ok for contracts/accounts that don't have a lot of transactions. Probably when it cannot do the sort in-memory anymore. I started tackling that one in #809 but it's still in progress.

However, this PR solves a slightly orthogonal problem since the related_accounts query was actually the wrong query for this specific case.