Harden the initial deal-observer implementation

[NikolasHaimerl]

There are a number of issues that were created during the implementation of Spark v1.5. This issues categorizes these issues into those which are critical and non-critical for hardening the implementation, those which are quick and easy fixes and those which are expected to need more time to complete.

Critical + Low Effort

Critical + Moderate Effort

• Piece Indexer Missing CIDs #30 --> feat: check for missing payload #77
• Handle Limit on archive retrievals #57

Critical + High Effort

• Periodically add new deals to spark-api's database of eligible deals #26

---

Non-Critical + Low Effort

• Sentry Error reporting #28
• Remove use of T.Object for TypeBox #43

Non-Critical + Moderate Effort

• Exponential Backoff for continous loops #21
• Remove obsolete mocha types #38 --> fix: removed mocha types #82
• Repository design pattern for database access #44
• Enable strict TypeScript checks #51 --> chore: enable strict type checking #80
• Test Main Loop Function #61 --> chore: extract observer loop and add tests #81
• Speed up payload update query #64

Non-Critical + High Effort

• Handle reverted events #22 --> add reverted field to database and expose telemetrics for reverted events #97
• Track usage of StateMinerInfo #49
• Skip Cloudflare for internal pix calls #50

[juliangruber]

Great structure in this issue 👏

[bajtos]

• Repository design pattern for database access #44

Let's remove this task from this milestone.

• We are pretty much done with features that require design/architectural work in spark-deal-observer.
• Next, we want to add support for Curio. Looking at the tasks in Spark DDO support for Curio, they don't seem to require changes in the way how spark-deal-observer queries the database.
• Finding a good design for the repository pattern requires non-trivial effort and most likely more than one round of discussion. We need that time elsewhere.

We can take another look at introducing the repository pattern when we work on features that could use a better design for database integration, e.g. when adding a REST API exposing the active_deals table.

[NikolasHaimerl]

• Repository design pattern for database access #44

Let's remove this task from this milestone.

* We are pretty much done with features that require design/architectural work in spark-deal-observer.

* Next, we want to add support for Curio. Looking at the tasks in [Spark DDO support for Curio](https://github.com/CheckerNetwork/roadmap/issues/231), they don't seem to require changes in the way how spark-deal-observer queries the database.

* Finding a good design for the repository pattern requires non-trivial effort and most likely more than one round of discussion. We need that time elsewhere.

We can take another look at introducing the repository pattern when we work on features that could use a better design for database integration, e.g. when adding a REST API exposing the active_deals table.

Should we also remove #51 from this issue? It would fall into the same logic as We are pretty much done with features that require design/architectural work in spark-deal-observer