Query skeleton for expansion of deposition page

[vincent-czi]

NOT INTENDED FOR MERGE

I've put this up as a draft PR on GitHub mostly as a way to provide a pleasant view of the diffs and to have a place to attach notes on what's going on here. The code as-is though is definitely not intended to get mergeg. This is a scaffold for the rough approach I see to handle the deposition expansion specs. The queries are -- I hope -- mostly there, but the usage definitely is not.

It's possible these commits could get cherry-picked or even merge the whole branch into a branch that is working on the deposition expansion, but they absolutely should not go straight to main.

Notes on queries

You can see a vague example of usage plan for the various new queries in the "VINCENT_WORK" block on /depositions.$id.tsx page. That data then gets console logged out in a matching "VINCENT_WORK" block in the useDepositionById.ts hook as a way of easily viewing the results of this query in a browser.

Before we discuss usage, two things to note:

• Basically everything comes in either an Annotation or a Tomogram "flavor". While we could think about a lot of this stuff as being good for a boolean OR query, after thinking about it more, that doesn't really make sense. The expanded deposition page shows either Annotations or Tomograms depending on which "tab" you have selected on the side. So while a given dataset or run may be associated with a deposition, it may have 0 annos or 0 tomos, and we only want to display it based on the anno/tomo tab flavor the user has selected at the moment.
• I ran out of time while working on this because I'm about to move houses. I think I fleshed out everything for the annotation flavor of queries, but I definitely had to skip a bunch of the tomogram query versions. I'm hoping the tomo versions will be pretty similar to the anno queries, but it's possible there will be something tricky in there, I only had the chance to write and test out my anno queries. Sorry!

Sketch of expected usage

With the above in mind, I'm going to just sketch out the user looking at annotations (well, annotation shapes, but let's just call it annos for simplicity from here out). The tomo approach should be pretty similar. Here's how I expect usage will work:

1. The user loads the page, and gets paginated annos available for the deposition (GET_DEPOSITION_ANNOTATIONS).
2. In the background, we fetch all the datasets associated with the deposition (GET_DATASETS_FOR_DEPOSITION_VIA_ANNOTATION_SHAPES and GET_DATASETS_FOR_DEPOSITION_VIA_TOMOGRAMS).
3. From the above, the FE creates a list of all datasets associated with the deposition to populate the "Filter by" for datasets. Additionally, since each dataset says its organism, we can create a look-up between organism name and its set of datasets to power the "Filter by" for organisms.
   • I am sorry, but I didn't have time to write this code!
   • The filters should probably populate as the combination of anno and tomo info, not just the currently selected flavor. That said, we'll still need to retain the anno/tomo-specific dataset info for handling the "Group by" tabs since there's no reason to show datasets or organisms where there is nothing for the currently selected flavor.
   • Per Slack conversation, we want datasets with a null organism to be presented as "Not specified". I think the code that rolls up the query result into the look-up is probably the right place to do this swap.
4. If the user runs a "Filter by", we get paginated annos available for the deposition based on the filter (GET_DEPOSITION_ANNOTATIONS_FOR_DATASETS). Because we only need to support filtering by dataset or organism, this can be accomplished entirely by filtering the data for _in some list of datasets (since an organism is just a collection of datasets).
5. If the user selects a "Group by" for organism, we don't immediately need a query at all. Instead, we present the list of organisms from (3) above with all of them initially closed in the accordions. We have the annotation count for each dataset from query (2), so we can sum those up based on the list of datasets that make up each organism.
   1. When the user opens an organism's accordion, it's almost identical to the query we use for the "Filter by" on organism (GET_DEPOSITION_ANNOTATIONS_FOR_DATASETS). The only difference is that we need to change the page size because the UX for an open accordion has a different count of items than when it's a filter and no accordions.
6. If the user selects a "Group by" for deposited location, we need three queries, and they build on each other.
   1. For the initial level of accordions -- showing all datasets -- we need the count of anno runs for each dataset. This is provided by GET_DEPOSITION_ANNO_RUN_COUNTS_FOR_DATASETS. We already have the annos count for each dataset via (2) above, so we don't query that here just use it from earlier info.
   2. Upon opening one of the dataset accordions -- and thus the user selecting a specific dataset id -- we need paginated info on the anno runs for that dataset along with the count of annos for each run (GET_DEPOSITION_ANNO_RUNS_FOR_DATASET).
   3. Finally, upon opening a run sub-accordion -- and thus the user selecting a specific run id -- we need the paginated annos info for that run within the deposition (GET_ANNOTATIONS_FOR_RUN_AND_DEPOSITION)

Random side note about pagination weirdness

FYI, I had a weird moment where I was validating one of my queries, trying to change the page number I was passing and see the results change as the limit offset moved. But the results kept coming back the same. It's like the FE app either was ignoring the updated page value or not interpolating it into the limitOffset or the BE was ignoring the offset. But then it started working as expected? I forget if I rebooted my dev server or did something else. Totally possible it was just error/confusion on my part. But if you see anything weird about pagination not seeming to update, try rebooting the dev server or closing your browser page or something before thinking it's a real bug.