feat(hogql): PersonsQuery

[mariusandra]

Problem

Splitting out work from #17470

Changes

• Creates a new PersonsQuery, similar to EventsQuery
• Unlike the existing PersonsNode, this query uses ClickHouse instead of Postgres
• Adds a flag to swap between the old and new queries on the /persons page and on the cohort edit pages
• New route to load persons by UUID (/persons/:UUID vs /person/:distinct_id) to avoid making a join we don't need at this point.
• Adds all the goodies from the event explorer like "add column right" to the persons table

How did you test this code?

Wrote tests for the backend, clicked around a lot in the interface for the frontend.

Out of scope

• Adding a source field to PersonsQuery, and hooking it to the LifecycleQuery or TrendsQuery.
• There are other frontend person tables that might need to be migrated. Group pages come to mind.
• Adding the Column Configurator
• The search for persons currently only uses the "name" and "email" fields (and distinct_ids), although we have a person_display_name_properties field on Team. This field contains 7 properties by default (email, Email, name, Name, username, Username, UserName). I didn't want to put all of them into the filter, as property extraction is a heavy operation. Doing it 5-7 times for properties a team doesn't have (and which isn't likely materialized) will make the query really slow. So I kept the current behaviour.
• For heavy users, we'll likely need to add code that moves the person filters inside the raw_persons table.

[mariusandra]

All right, I think this is ready for a review. The description has been updated with what is still in scope of this PR, and what will follow.

[thmsobrmlr]

Looks good from what I can tell.

If we're not intending to ever cache the persons query, we should probably implement a variant of the query runner without caching. I initially missed that we use QUERY_WITH_RUNNER_NO_CACHE to call calculate instead of run.

[thmsobrmlr]

Are we intending to cache this query at some point? Otherwise we should properly implement a query runner without caching, so that we don't make unnecessary requests to Redis and Prometheus.

[mariusandra]

Thanks for the review! Regarding caching... I'm not sure. It might make sense to cache some of the results, so e.g. the flow of persons -> person -> back is fast even if we make another request. To be continued... :)