add reverted field to database and expose telemetrics for reverted events

[NikolasHaimerl]

This PR proposes the following changes:

1. Add the reverted field to the table of active_deals
2. Count the number of reverted active deals and add them to InfluxDB

The implementation plan for this PR can be found here.
Closes #22

[bajtos]

On second thought, I don't think a deal can be reverted. It's only an event that's reverted. While I am not entirely familiar with how this works on the Filecoin side, I would expect a sequence like this:

• Event 1 is emitted, uses e.g. sector: 123
• Chain re-org happens, deal fields change
• Event 1 is reverted
• Event 2 is emitted. Most of the fields from Event 1 are preserved, but some are changed, e.g. sector: 125.

To correctly handle that sequence, we need to remove a deal from active_deals when an event was reverted, so that it can be added again in the future.

Or maybe we can treat reverted: true as a soft-delete flag? But then the loops looking up payload CID and uploading deals to spark-api must be updated accordingly.

I think it would be best to not make assumptions and either find documentation of ask FilOz team to better understand what's the correct way to process reverted claim events.

[NikolasHaimerl]

On second thought, I don't think a deal can be reverted. It's only an event that's reverted. While I am not entirely familiar with how this works on the Filecoin side, I would expect a sequence like this:

* Event 1 is emitted, uses e.g. `sector: 123`

* Chain re-org happens, deal fields change

* Event 1 is reverted

* Event 2 is emitted. Most of the fields from Event 1 are preserved, but some are changed, e.g. `sector: 125`.

To correctly handle that sequence, we need to remove a deal from active_deals when an event was reverted, so that it can be added again in the future.

Or maybe we can treat reverted: true as a soft-delete flag? But then the loops looking up payload CID and uploading deals to spark-api must be updated accordingly.

I think it would be best to not make assumptions and either find documentation of ask FilOz team to better understand what's the correct way to process reverted claim events.

As this PR only focuses on the observability of when events with a reverted filed set to true occur, does your suggestion influence this PR?

[sentry-io]

Suspect Issues

This pull request was deployed and Sentry observed the following issues:

• ‼️ Error: Connection terminated unexpectedly countRevertedActiveDeals(resolve-payload-cids) View Issue

_{Did you find this useful? React with a 👍 or 👎}