Add environment variable validation to the build script

[Gudahtt]

Currently the build script doesn't validate that expected environment variables are set for production builds. This is because the build script doesn't know the difference between a real production build and a production-like build. We have one build target (yarn build prod a.k.a. yarn dist) that we use for local testing and for the real prod build, and environment variables are the only difference between the two. There's no way for the script to know whether a missing environment variable is intentional or not.

We should split this single build target into two: one target for production-like builds, and one for a real production build. The real production build target can include comprehensive validation that ensures all expected environment variables are set.

[brad-decker]

@Gudahtt would this also allow us to only do post fenced code linting on real - prod builds or in the presence of a flag? I believe (hunch) that a bulk of the lavamoat:auto time spent is the linting of these files which cannot be cached like normal lint. I was hoping to either implement a checksum cache-key tool for eslint for the fenced code checking so that if the generated files are unchanged from the last run that linting would be skipped for that file OR provide a script flag for lavamoat:auto that bypasses linting if your primary concern is simply to fix policy overrides etc errors that pop up from running this script.

Curious to hear your thoughts

[Gudahtt]

Those two ideas sound promising. I don't envision the new dist target as helping with that goal, because neither the existing dist target nor the new prod target are directly used by lavamoat:auto. lavamoat:background:auto uses an internal task (scripts:prod) with the --policy-only flag set, which is supposed to tell the build system to do the minimum work necessary to generate the policy.