Send X-GitHub-Api-Version when calling [GitHub] v3 API

[chris48s]

Closes #8665

This PR does three things:

1. Sends the X-GitHub-Api-Version header when calling the GitHub v3 API
2. Adds a scheduled GitHub workflow to:
   • Call https://api.github.com/versions
   • Find the latest version by date
   • Read in config/default.yml
   • If $date != public.services.github.restApiVersion:
     • sub in the new date + write config/default.yml
     • push to a branch
     • submit a PR update [github] api version
3. Tangent: Fixes a long-standing bit of oddness: github-constellation.js has been ignoring the config.service.baseUri setting and reading straight from the env var. I guess most people either don't configure this or configure with env vars anyway, so it has gone unnoticed.

[shields-ci]

	Warnings
⚠️	This PR modified the server but none of its tests. That's okay so long as it's refactoring existing code.
⚠️	📚 Remember to ensure any changes to config.private in services/github/github-constellation.js are reflected in the server secrets documentation

	Messages
📖	✨ Thanks for your contribution to Shields, @chris48s!

Generated by 🚫 dangerJS against 08edb6c

[calebcartwright]

Fixes a long-standing bit of oddness: github-constellation.js has been ignoring the config.service.baseUri setting and reading straight from the env var.

Though a fix, imagine there's a non-zero chance of this impacting a self-hoster? May warrant a special call out in the next server relnotes

[chris48s]

If you are currently setting this via GITHUB_URL then it will carry on working as before. services.github.baseUri is set from GITHUB_URL anyway

shields/config/custom-environment-variables.yml

Line 39 in 41c53c7

baseUri: 'GITHUB_URL'

so no change there.

I think the only case where this might cause a behaviour change would be if someone is hosting (using a source install, rather than docker), they edited services.github.baseUri in the yaml config (which would have no effect) and then they update to this release and suddenly their custom services.github.baseUri starts actually doing something.

Is that the case you were thinking about?

[calebcartwright]

Is that the case you were thinking about?

Precisely. Someone who has a value in there that they forgot about which currently is a no-op but which would become operational once they pulled in this next version.

Obviously not saying we shouldn't do it, but it's the type of thing I'd put at/near the top of the release notes to call it out specially

[chris48s]

Yep OK. I'll note this when I assemble the changelog for the January release. We need to call out the change to the GH workflows route there too.