feat(cbrs): Time Window Routing

[volokluev]

This PR implements a routing strategy for routing to TIER_1 and instead of downsampling storage tiers, shrinking time windows.

Design decisions

Window Sizing Algorithm

This is the easiest thing to change in this PR (and likely it will change). At the moment, it looks up the amount of outcomes for the requested time range and shrinks the time window down assuming that the distribution of datapoints is uniform across time (which is not true). Most recent datapoints are prioritized first

Pagination

Only the TraceItemTable endpoint makes use of the recommendations of this routing strategy, the endpoint and routing strategy interact across queries. This is to facilitate a simple client side UX where all the client has to do is pass the page_token across their requests and not worry about anything else.

Here's a diagram explaining the flow:

┌─────────────────┐              ┌────────────────┐                               
│                 │              │                │                               
│                 │              │                │                               
│                 │              │   Routing      │                               
│   Client        ├─────────────►│   Strategy     ┼───────────────────┐           
│                 │  page_token  │                │                   │           
│                 │              │                │                   │           
│                 │              │                │            Narrows│time window
└─────────────────┘              └────────────────┘            For Endpoint       
        ▲                                                             │           
        │                                                             │           
        │                         ┌────────────────┐                  │           
        │                         │                │                  │           
        │                         │                │                  │           
        │                         │ TraceItemTable │◄─────────────────┘           
        └─────────────────────────┼ Endpoint       │                              
             Encodes              │                │                              
             Time Window          └────────────────┘                              
             In Page Token                                                        

In order to facilitate pagination, the TraceItemTable endpoint now queries for limit + 1 rows in order to know if there are more items in this current window or if we can move on to the next one

What's missing

1. This functionality can be tested more rigorously, I deliberately did not spend too much time on it because I know it will change and the priority is to get something out there to try
2. We could probably have more observability into what the strategy is doing and understanding our success metrics better. These will be added as we understand the problem more

[xurui-c]

when does this function return None?

[volokluev]

if there is no adjustment to be made

[xurui-c]

Is this so we prioritize more recent data? and the user will paginate forwards?

[volokluev]

correct

[xurui-c]

where is this used?

[volokluev]

debugging :D

[volokluev]

this is how we actually shrink the time window

[volokluev]

copy pasta, remove

[volokluev]

copy pasted, remove this

[volokluev]

this is wrong, the default should not be span indexed

[codecov]

✅ All tests passed in 1293.61s