[feature]: unify release build methods

[jtobin]

At present we have a couple of canonical ways to build releases, namely make release and make docker-release, and these can produce different artifacts depending on the environment used for the build. We also have some instructions to use make docker-release in docs/release.md, but use make release in CI, leading to reproducibility problems like that discussed in #1874.

We should have one canonical method by which to create a totally reproducible and verifiable release build, anywhere, and use that consistently. The release build docs should then be updated as well.

[ffranr]

As far as I recall, our earlier thinking on this was to aim for reproducible builds across different environments. We do not want the reproducibility check and its security properties to depend on a single Docker image, for example. The goal is not just reproduction per se, but reproduction across diverse environments, demonstrating that the source-to-binary mapping is consistent.

[Roasbeef]

make docker-release is for building on Mac. By default we'll get a different end archive but matching binaries.

Based on the above, I think this can be closed.

[jtobin]

As far as I recall, our earlier thinking on this was to aim for reproducible builds across different environments. We do not want the reproducibility check and its security properties to depend on a single Docker image, for example. The goal is not just reproduction per se, but reproduction across diverse environments, demonstrating that the source-to-binary mapping is consistent.

Summarizing my understanding of an out-of-band discussion we had around this, for posterity.

My primary focus here is that we have a build that can produce totally reproducible artifacts. I.e., we can establish a hermetic build environment containing only explicit inputs (host architecture/platform, toolchains, utilities, source, etc.), build our stuff in it, and thus get fully deterministic outputs.

(N.b., it strikes me as likely that make docker-release may mostly fit the bill for this already, but the use of apt-get update and apt-get install for build utilities in the corresponding Dockerfile gives me pause. Seems we would want to bake an image that used consistent versions of these utilities, updating that image as needed.)

Whatever that tool is, anyway, we should exclusively use that to produce release builds, particularly in CI, and direct others to use it as well. Per @ffranr's point, this build should not depend strongly on some particular inputs (like a single docker image), but rather the build must allow precise specification of the inputs (which may be some particular docker image, but possibly some other docker image).