Although I wanted to change the database query to be direct instead of through the API server, for expediency's sake + don't-fix-what-ain't-broke, I'll stick with the API server counts implementation and commit a thinner version of DataAccessor for now.

test/apiserver/unit_tests/record_counts1.txt and build/build_scripts/expected_table_counts.txt are identical. Is this redundancy necessary?

This work entails updating the documentation in spt-data:
https://github.mskcc.org/mathewj2/spt-data/tree/main/findings

Also, I suppose, committing the plot specification artifacts to spt-data for now. Similar to findings.

All tests pass except for workflow tests, which complain about default_study_lookup not being present. Not sure if it's unrelated or if the change to the first test database broke something.

I would check that the new system of data-preloaded-images is getting used (in a recent update I moved these images to docker hub, so development doesn't require building them locally).

test/apiserver/unit_tests/record_counts1.txt and build/build_scripts/expected_table_counts.txt are identical. Is this redundancy necessary?

We will have to check usage, probably the idea was that the test and build scripts would not need to reach into each other's directory contents.

If the data loaded images live remotely, and I've modified one of the data loaded images to have two importance score studies so the plotting has something to compare, would that cause an issue?

Yes, this is the scenario where, when this PR is complete, we would update the docker hub images.
I suppose for now you would need to make sure that your development setup is using your locally-built images. I'm not sure what docker does when both remote and local are available, I think it depends on the pull policy.

Tests passed.