perf(eventstream): Add caching layer, raise sort

[thetruecpaul]

Two changes:

1. Add a caching layer so that we can avoid hitting the DB for hot groups.
2. We don't need the sort in 95% of cases. Let's raise that into Python and only do it when necessary.

[codecov]

Codecov Report

❌ Patch coverage is 96.96970% with 1 line in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
.../sentry/services/eventstore/query_preprocessing.py	96.96%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##           master   #103756    +/-   ##
=========================================
  Coverage   80.59%    80.60%            
=========================================
  Files        9274      9279     +5     
  Lines      395956    396164   +208     
  Branches    25250     25250            
=========================================
+ Hits       319138    319320   +182     
- Misses      76389     76415    +26     
  Partials      429       429            

[wedamija]

I have some broader concerns about how we're doing this. It looks like for every snuba query that uses SnubaQueryParams we're potentially making multiple calls to postgres? The caching will help here, but we've added 1000s of queries a second to the database. Let's see if this drops a lot and then maybe we need to revisit this solution in general.

I think it's surprising behaviour that just initializing SnubaQueryParams causes postgres queries

[wedamija]

Should this just be a dict of <group_id>: <max_date>? So when we add rows in later, we just do running_data[group_id] = max(running_data[group_id], new_date)?

[thetruecpaul]

I find the set easier to reason about and don't think there'll be that much duplication (only expect one Redirect per group)