Fetching metadata from IPFS fails without retry

[Jipperism]

Sometimes fetching the metadata from ipfs fails, as it (presumably) hasn't been pinned by IPFS yet, and we receive a timeout. Fetching it seconds later manually does return the correct json. The goal of this issue is to come up with a proper solution for this problem.

We have a number of options.

1. Make a generalized failed event queue. That means that any event that doesn't get indexed properly would be retried automatically. It's more involved technically, and it would have to preserve the state of events that need to be "re-indexed" across indexer deploys/restarts.
2. Setup a cron job (similar mechanism to what we use in the API) that checks for all metadata with parsed: false periodically, and tries to re-index those specific metadata entries. This would probably be the easiest and most straightforward to implement.
3. Keep retrying the current event until ipfs resolves, not a good option as it would block indexing for a undetermined amount of time.

@bitbeckers @pheuberger do you have an opinion on what the best approach would be here?

[bitbeckers]

Imho, option 1 is the preferred one. We already have a DB paired in the Railway environments for caching call data (like IPFS or blocks). We can probably easily add a table there that can be the event queue.

option 2 sounds reasonable as well, but I think that a) we shouldn't keep adding cron jobs, if they all burst at the same time we're hitting rate limits and b) this is a fix for a specific scenario where option 1 basically works for all calls that fail (looking at you FVM RPC)