Add WMG API functional tests

[atolopko-czi]

The functional tests should be able to identify

1. Compatibility regressions for snapshot data artifacts that might be introduced by the backend API layer
2. Performance regressions in either a) the backend implementation of TileDB queries, or 2) the WMG cube, due to schema changes or data contents (overall size, or change in data characteristics).

Acceptance Criteria:

• On dev, staging, prod branch deployments, functional tests are run on GHA, using the "latest" WMG cube snapshot on S3 (i.e. real data)
• Engineers can run performance tests locally via makefile target, against the "latest" s3 snapshot.
• Tests exercise and pass "worst case": 4 tissues w/largest cell type counts, 400 genes, no secondary filtering: < 5 seconds (prod env instance size)
• Tests exercise and pass "common case": 1 tissue w/50 cell types, 20 genes, 3 secondary filters specified (known to affect result size): < 250ms (prod env instance size)

Note: tests do not need to verify correctness of returned data. They need only assert the non-empty results are being returned with performance meeting SLOs.

[MDunitz]

I think that 250 ms for the common case is out of reach for our current architecture. Currently (with the larger instance) we have a response time a little under 1.5 seconds

[atolopko-czi]

I think that 250 ms for the common case is out of reach for our current architecture. Currently (with the larger instance) we have a response time a little under 1.5 seconds

So that's the full request/response time (round trip) for the client, right? Do we know how this breaks down between TileDB query time and network I/O?