Analytics crate + downtime metrics between trades for a given time period

[epappas]

Motivation

We wanted to understand the "downtime" between trades as a critical KPI for evaluating the performance and responsiveness.

Currently we're lacking a crate focusing on the analytics part for the future metrics we want to expand on, limiting visibility into creating KPIs.

Solution

This proposed change introduces the downtime metric (min, max & avg) for the time intervals between consecutive trades, irrespective of the orders (gathers all).

Example:

let (avg, min, max) = analytics.calculate_downtime_between_trades(Some((start, end))).await;

println!("Average downtime: {} seconds", avg);
println!("Minimum downtime: {} seconds", min);
println!("Maximum downtime: {} seconds", max);

and at the cli:

cargo run -p rain_orderbook_cli analytics downtime --start=01-11-2024 --end=20-11-2024 --subgraph-url=<url>

The current implementation relies in gathering all orders and then sorting the trades in order to calculate the needed time deltas. A potential enhancement is to go directly on chain and get the transfers, as we rely on subgraph crate for now, which gives us the orders.

Checks

By submitting this for review, I'm confirming I've done the following:

• made this PR as small as possible
• unit-tested any new functionality
• linked any relevant issues or PRs
• included screenshots (if this involves a front-end change)

[epappas]

I'm creating this for two reasons:

1. To make the code more testable
2. To not pollute the OrderbookSubgraphClient with analytics-related methods

[epappas]

Note: IMO this should had been provided as a mock interface from the subgraph crate.

[hardyjosh]

makes sense - can you move it over there?

[epappas]

I can, but this particular block is very ugly and opinionated for this set of unit tests. Also out of scope of this PR i'd say.

What I's thinking was some sort of a testing crate that creates fake trades & orders for a given scenario.

[epappas]

I don't like the performance output of this, but to fix that, would had been out of the scope of the PR.

[epappas]

I'm sorting the trades, as it's not guaranteed that the orders will give me chronologically sorted trades.

[epappas]

change in the original API. Added --threshold cli param (eg --threshold=1m) and total & count downtime metrics.

example:

rain_orderbook_cli analytics downtime --threshold=35s --start=01-11-2024 --end=20-11-2024 --subgraph-url=***
Average downtime: 1356.39 seconds
Minimum downtime: 36.00 seconds
Maximum downtime: 5206.00 seconds
Number of occurrences: 1207
Total downtime: 1637160.00 seconds

using the analytics crate

let (avg, min, max, count, total) = analytics.calculate_downtime_between_trades(period, threshold_secs).await;

println!("Average downtime: {:.2} seconds", avg);
println!("Minimum downtime: {:.2} seconds", min);
println!("Maximum downtime: {:.2} seconds", max);
println!("Number of occurrences: {}", count);
println!("Total downtime: {:.2} seconds", total);