Remove unnecessary nix build dependencies from docker image

[tegefaulkes]

Specification

Following #399 We've reduced the size of the docker image to less that the previous size. But digging deeper into the image we found that there are extra nix store paths that are being included which may not need to be there. Mainly there is the inclusion of the polykey-cli so there is at munimum, 42MB that doesn't need to be included.

The nix store seems to be determined by the nix dependencies of the derivation being copied to the docker image. When testing I saw that these are included after the contents are copied to root. So its not possible to remove the nix dependencies using an extra build script.

Additional context

• Contunuation from Reduce size of docker image build output (after ESM Migration) #399

Tasks

1. Identify why polykey-cli is being included in the nix store paths of the docker image.
2. Ensure that only runtime dependencies are included in the docker image.
3. Apply the fix.

[linear]

ENG-613

[CMCDragonkai]

Fundamentally this is determined by 2 things. The `buildNpmPackage` and `dockerTools`. I already think: 1. The real culprit is the way docker tools work and you should investigate how to change to using OCI tools and build a more minimal image. 2. There may need to be an intermediate derivation that filters out the output of `buildNpmPackage`. 3. A third way which may be better is to instead change the main nix store output to use the bundled executable rather than `buildNpmPackage`. This is because our esbuild bundled executable contains the node runtime statically bundled. Right now that node runtime is being fetched from the yao PKG ecosystem. We need to instead directly build cross-compiled node runtime directly. I have investigated this a while back and it is definitely feasible. In fact one can also use upstream node binaries - and patch them before bundling. For a fully secure sovereign supply chain, we should be compiling directly from source to avoid node ecosystem supply chain risks. And this enables us to customise the node runtime directly and make it specific to our usecase. This also opens up the opportunity to use more modern runtimes like bun or deno - but mainly require changes to ES compatibility and native code compatibility. If at some point they become wasm, it may be possible to eventually get it onto mobile OSes.