fix firehose eth CallHandler triggering on reverted calls

[sduchesneau]

firehose exposes calls that are "failed" or "reverted". current behavior is to only filter out the transactions that are completely reverted (from the status in the Receipt).

This fixes POI inconsistencies seen in QmPDp878JK2RcvXNhWX1UQHYbhF8iEcWPTdnP9bJvy6L6P (and hopefully QmUrfWjK7rdXzbr3q6D2DVDapCw4yWBU88qjrNvZUewoNy too)

Additional notes

• Current filtering from RPC traces is done on the existence of the error field. This field does not exist in firehose calls, so we must use another firehose-specific field.

• UPDATE -

• issue Bug: Call handler improperly invoked when call was reverted on-chain #3701 shows us that we shouldn't only skip calls that are failed, but any call that is reverted too (calls are reverted if their parent is reverted).
• In firehose, this means that we must use state_reverted field to correctly skip calls that had no effect on the chain.
• In RPC, it is more complex to fix.

We need to be able to compare existing POIs from RPCs with POIs from firehose to ensure that the transition is successful, so this PR will make firehose mimic the RPC behavior (and not fix #3701 for the moment).