Add nix flake to support building with nix

[silky]

Hello!

This PR introduces a nix flake to support people wanting to build this project via Nix.

Notable features are:

• Flake for building go, Python and the (v2) frontend (also the v1, just incase it is required)
• devShell for running the Makefile
• Package to build the entire docker image (b6 + v2 ui) nix build .#b6-image
• CI job to test that the tests run in the devShell
• Readme updates describing Nix tooling
• Minor changes to accomodate package building via Nix

~Perhaps the most controversial change is the last one. The main change is commit the pyproject.toml file so that the Python packaging process can pick it up. It might be possible to not do this; but given that there are other locations where the version is hard-coded in the source (which I think is fine) it didn't seem like too big a crime.~

Let me know what you make of it!

Note that I've gone to some effort to maintain backwards compatibility; i.e. this does not break building the project for anyone not using Nix; and indeed the main Makefile is still the preferred way to build. But it does open-up the path for more nixification; and enables nix people to hack on the codebase :)

Trivia/Open questions:

• ~There is a bit of a quirk with the git describe --tags way of getting versions and I'm not 100% sure the CI will work the first time here. On my fork, I had to explicitly override (😱 😱 😱) the v0.0.4 tag; but I think it's a quirk with how Github checks out the repository; I'm 🙏🏻 ing that it will "Just Work" when the Github action runs here on the main repo. But I'll be curious to see.~
• ~I realise also that there is cloudbuild.yaml defining CI workflows as well; but perhaps one could move the Nix check there instead; but it doesn't seem terrible to run it via Github Actions. I'm open to ideas here.~
• I restored a package-lock.json and set a version to 0.0.0 in js; as both these things are required by Nix.

[silky]

I "fixed" the version issue in pyproject.toml; but it comes at a moderate cost.

In investigating it, I realise now that there is something a bit odd in how b6-api reports the version. Note that the version is computed by running git. So it would seem that this will depend on the directory that this command is invoked from? I actually at this point can't quite understand how it even works. I do get different results depending on where I am:

b6 (add-nix +) > ./bin/linux/x86_64/b6-api --version
0.0.5-a.655.ga4cee54
b6 (add-nix +) > cd ..
diagonal> ./b6/bin/linux/x86_64/b6-api --version
0.0.4

But note that in the second case, I'm not in any git repo at all!

Not quite sure what to make of that. Appreciate any insight :)

-- Edit:

Ah, of course, the code has:

...
if !inGitRepo() {
  return ApiVersion, nil
}

So, fine, everything makes sense.

[silky]

I suppose the main difference is that when the Makefile builds the pyproject.toml, the version in there is the one from the current revision in the git repo; i.e.

version = "0.0.5a655+ga4cee54"

but the Nix build doen't run b6-api in any git repo; so the version there is 0.0.4.

This isn't a big deal for the time being (given that the nix python build isn't even depended on yet; aside from via the tests in CI) but is worth noting.

[silky]

I added a couple of commits to now also build the docker image via Nix.

I haven't tested it extensively, but it seems to do the right thing now, and brings in all the dependencies in a nice way. I had to make a couple of changes to the source; but nothing too controversial I hope (i.e. nothing breaking).

[silky]

Last commit makes a few code changes to standardise the way test-data is loaded, and default to looking up the go.mod file to find the root directory from which to load tests.

Again, these changes shouldn't break any "normal" go building/testing, but just make it compatible with Nix :)