Client function for new metrics endpoint

[macfarlandian]

Description of the change

Encapsulates metric fetching from the Spotlight API /public endpoint in a fairly straightforward function. (It doesn't look terribly different from the proof of concept in #257.)

Somewhat less straightforward, but maybe kind of fun, is the testing strategy: rather than creating a potentially brittle mock, I just integrated a real server from the spotlight-api package into the client tests. This runs on a designated port and serves up the "demo" fixtures. Jest is able to provision and destroy this server programmatically as part of its global setup and teardown configuration, so we don't actually have to do anything special to run this integration test beyond making sure the test environment is properly configured in .env.test. (This is a new requirement for development so I have added it to the README as well.)

(This works fine locally but the test process has a mysterious tendency to hang after it's finished in the CI job. I am just forcing the process to exit, which is a little dubious but seems fine in this context? It's pretty hard to debug environment issues in Github CI so I am not inclined to spend time figuring this out unless someone is very offended by this solution.)

Type of change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Configuration change (adjusts configuration to achieve some end related to functionality, development, performance, or security)

Related issues

Closes #261

Checklists

Development

These boxes should be checked by the submitter prior to merging:

• Manual testing against realistic data has been performed locally

Code review

These boxes should be checked by reviewers prior to merging:

• This pull request has a descriptive title and information useful to a reviewer
• This pull request has been moved out of a Draft state, has no "Work In Progress" label, and has assigned reviewers
• Potential security implications or infrastructural changes have been considered, if relevant

[coveralls]

Pull Request Test Coverage Report for Build 397513533

• 8 of 10 (80.0%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.1%) to 58.79%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
spotlight-api/app.js	1	3	33.33%

Totals
Change from base Build 394943904:	0.1%
Covered Lines:	1060
Relevant Lines:	1760

---

💛 - Coveralls

[jovergaag]

Looks good! My only comment is something we've chatted about elsewhere, that changing fixture files will result in these tests failing, but as long as they are pretty stable then this looks great!

[jovergaag]

Are you going to point Sentry at this to receive notifications if it goes down?

[macfarlandian]

i don't know ... at the moment it was just needed for the tests to be able to determine when the test server is ready to receive requests. But yeah I guess we could use it for any normal uptime monitoring scenario also. Are we doing that with Sentry on pulse-dashboard?

[macfarlandian]

@jovergaag I expect them to remain pretty stable in this application, yes, so I think this is a safe trade-off. I don't expect we'll be in the habit of, e.g., refreshing them with new values periodically, so they should really only change if the schema changes.