Add nix build support

[farcaller]

I'm not sure you want this, but, given there are no releases for coredhcp and I can't add this into nixpkgs, here's an in-tree support for nix build tooling.

This builds only the coredhcp, in a reproduceable way.

[Natolumin]

So I have very little nix knowledge, can you explain a little how these are/were generated (especially gomod2nix.toml and flake.lock), and what we'd need to do to maintain them as the software and its dependencies evolve?
Ideally if we want this to be a supported build method (which I'd be personally inclined to), we would want to build this in CI to avoid it desyncing from the rest

[farcaller]

Sure, here's the TL;DR

shell.nix

this is a helper to get into the build shell. If you have nix installed, nix-shell will drop you into the shell with all build dependencies (e.g. go) resolved

default.nix

This is the build rule to build the app. If you run nix-build, this is what gets built (cmds/coredhcp specifically).

flake.nix

This is the package.json of nix world. The two above are the old way to do things, flakes are the new way. You can depend on other flakes, generate several artifacts, etc. In here it's basically declaring a dependency on nixpkgs (where all the packages come from) and gomod2nix (the go module nix builder), otherwise outsourcing the shell and build rules to the two above.

flake.lock

Is a lockfile for above. This is how the build is reproducible. This will (among other things) lock to a specific version of go.

gomod2nix.toml

Nix uses a different hashing system then go, gomod2nix converts go dependencies into something nix can verifiably fetch, cache, and rebuild.

Keeping it all up-to-date

Basically, you keep the nix deps fresh by running nix flake update (this updates the flake.lock), and go deps by running nix run github:nix-community/gomod2nix generate. Here's a sample GH action for the former and this one for the latter. Generally you'll have pretty low maintenance on keeping these up to date because it's a very low chance something will break due to the incoming dependencies.

The second example hooks to the dependapot PRs, keeping the gomod2nix lockfile fresh, but you can easily update it to run on any PR that changes teh go deps, of course.