chore(weave): Move call queries to the backend

[tssweeney]

Meta Comments:
This PR pairs with https://github.com/wandb/core/pull/21622. To reviewers: I am going to split this PR into 2 parts after approval:

1. Backend Changes: chore(weave): Call Table Migration - Backend #1691
2. Frontend Changes: chore(weave): Call Table Migration - Frontend #1692

The rollout will be:

1. Merge Backend Changes
2. Merge https://github.com/wandb/core/pull/21622
3. Deploy Trace Server
4. Merge Frontend Changes
5. Deploy Frontend

PR Overview:
This PR seeks to improve the performance of the CallsTable. It does so by moving the query layer (sorting, filtering, & paging) out of the MUIDataGrid and into the backend. Furthermore, it refactors ref expansion out of the component layer completely, and puts it in the network query layer (sets us up to move this to the backend next).

The benefits of this PR are:

• Improved, non-degrading performance characteristics for large projects' CallsTables
• Faster call counting queries around the application
• Technical foundation for query operations on expanded fields
• Technical foundation for "export to python" exactly what you see in the app
• Various UX improvements for ref expansion and handling of heterogeneous column types.
• Type-aware support for numerous filter types - including date filter on call creation.

User-facing changes:

1. Call attributes, inputs, output, and summary are all handled exactly the same in the CallsTable now.
2. RefExpansion feels exactly like: "Transform the ref into the data". Specifically:
   • Expanding Refs pointing to primitives are now supported
   • Expanding output is now supported
   • When you expand a ref that points to an object - the result is that it feels exactly like a dictionary is the
3. Type-aware support for numerous filter types - including date filter on call creation.
4. CallsTable is now paginated (100 per page)

Features Removed:
Note: I can add these back, but they have their own tradeoffs.

1. We no longer auto-hide sparse columns
2. We no longer have a "common columns" section
3. "Export as CSV" limited to immediate page

Backend Changes:

• New "mongo-style" filter can be passed to calls/query
• New CallsQueryStats endpoint that currently exposes stats

API Design Choices to Discuss

• Should change 'filterBy' to be part of the 'filter' clause? (probably?)
• Should change the total count to be part of the standard query? (probably not?)

Future Features:

• Support for Filter/Sort on expanded fields (in the backend)
• Sorting / Filtering by username should convert the id to internal id
• Would be nice to support sorting by common derived values like latency or version index
• Export as CSV supports the entire resultset
• When expanding a ref, the ref link goes away (for primitives) - would be nice to fix this

[circle-job-mirror]

Preview this PR with FeatureBee: https://beta.wandb.ai/?betaVersion=632834cca2b2bdab0693e8bac03cb86a94780450

[jamie-rasmussen]

In my experience, end users will absolutely do things like have "file.ext" or a string "123" as keys in an object. A dotted notation is very convenient for the common case but we may want to consider also supporting a more verbose traversal format like object[1]["file.ext"]["42"]

[tssweeney]

Added a summary of limitations here: 6f0e498 ... need to define this more crisply before opening up to public

[jamie-rasmussen]

Does the same thing in either case?

[tssweeney]

yeah - i just want to trigger on changes to resetDep. just putting resetDep in the dep array is susceptible to linter removing. I commented. Perhaps there is a better way?

[jamie-rasmussen]

This file is getting really big - would be nice to split it up.

[tssweeney]

I agree - i actually did refactor this, then reverted: b6668ac#diff-121d8320484a693356428be5657e6b61d53f293f5c505f49e67ccc91ac09d5e3 ... i was just touching so many things that i thought it would be better to come back and split this file up after

[tssweeney]

Closing - all of this is now landed using smaller separate PRs!