Calculate APR per peer based on redeemed tokens

[jeandemeusy]

As a prerequisite to https://github.com/hoprnet/gitops/issues/238 point 2, CT should calculate the APR per peer based on actual token redeemed instead of showing a projected value based on expected messages relays.
This requires to have access to each redeem ticket event and having them exposed to Prometheus.

[jeandemeusy]

Multiple attempts to get the redeem events on Grafana through subgraph have been done. Here's a TL;DR of each of them:

Getting them from CT, and publishing them as a Prometheus metric

This seams as the easiest way to do it. However, as the tickets have their own timestamps (when the ticket has been redeemed) which differs from the metrics timestamps themselves, the tickets timestamps have to be part of the labels. This is a bad idea as each time prometheus gets the metrics from CT, it would duplicate the same information again and again, increasing the amount of data stored, which increases the cost of Prometheus.

Getting them from Grafana (plugin Wild GraphQL Data Source) by listing tickets

This seams nice too, as it decouples getting the redeemed tickets from CT. However, GraphQL has a limit of returning 1000 entries per query. One can pass (first: 1000, skip: $skip), to define which 1000 items are to be returned, but the Grafana plugin doesn't support this feature to automatically get all the entries by doing multiple calls.

Getting them from Grafana (plugin Wild GraphQL Data Source) by listing accounts (node addresses)

This is a workaround that could be ok until the network is 1000 node big. The method would be to query all accounts (less than 1000, so it's ok for GraphQL), and ask for all tickets from all channels related to those accounts. However, the amount of data retrieve is enormous, and we obviously need to filter it by issuer, to only keep CT nodes as issuer. This is not possible, as the data structure returned is a nested list of nested object.

Getting them from Grafana (plugin Wild GraphQL Data Source) by listing channels

Same issue as for the previous attempt, except that we can not even have all the channels, as there's more than 1000.

What could be tested

• Replace the Grafana plugin with Infinity
• From CT, storing tickets in a database that would be queried by Grafana
• Use Dune (having a proper dashboard would be hard there, as we are not paying for Dune. For each peer we would have to go the query itself and run it manually)
• override the prometheus exporter on CT's side and use the metricpusher to allow custom timestamps for metrics.

Last resort

• Having the dashboard offline as a Jupyter Notebook or something similar.