Add Enketo version (release tag, or git commit hash, or package.json version) to User-Agent header to server-sent requests

[eyelidlessness]

Closes enketo/enketo#1021. Only opening as draft because I've done no manual testing, but want to make it available for review.

I have verified this PR works with

• Online form submission
• Offline form submission
• Saving offline drafts
• Submitting offline drafts
• Editing submissions
• Form preview
• None of the above

What else has been done to verify that this works as intended?

Expanded test coverage of config.version.

Why is this the best possible solution? Were any other approaches considered?

This is probably not the most thorough "version" determination for all scenarios (relevant discussion in #382), but we're hoping to address that. For now, the goal is to reuse the same logic so it can be updated in one place.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

If Enketo is linked to a server which is not expecting this header I suppose it could cause unexpected behavior? But that seems exceedingly unlikely.

Do we need any specific form for testing your changes? If so, please attach one.

N/A

[yanokwa]

When I tried this on the QA server, Enketo wouldn't load because express-cls-hooked was missing. It's marked as a dev dependency, so npm --prune production removes it.

[eyelidlessness]

Oof, muscle memory misfire! Fixed.

[eyelidlessness]

Part of my manual validation step is looking at the User-Agent displayed on submissions in Central. I'd assume that edits should not change the value of the original submission—and it did not change—but I do wonder whether we're also capturing UA on the Central side for edits.

[lognaturel]

whether we're also capturing UA on the Central side for edits.

As confirmed by @matthew-white, it's captured and API-accessible, just not in the frontend yet!

version does not account for git refs on forks, which would be an issue when deploying unmerged changes for testing.

I think it can be dev responsibility to keep track of what branches they've tried out. I'm not too worried about this. If it ends up being a pain point we can come back to it.

All of this is looking great to me now. The only last remaining issue I see is that the file written out in the case of no git environment seems to have a trailing newline. It now gets sanitized as a space so it works but it looks a little funky.

[lognaturel]

This caused a memory leak fixed in #450. As @eyelidlessness says there, "Continuation Local Storage (whether using async hooks or not) isn't a great idea in the first place" but it was a pragmatic approach to get this functionality in.