Add Dockerfile for building orchidd

[jcvernaleo]

I plan on providing additional docker and docker-compose files for actually running orchid in future PRs but decided it would be easier to start with one since I wasn't sure where the best place to put these in the repo was and to make sure everyone is happy with the format of things. Happy to move this any place you suggest.

[jcvernaleo]

Thanks for the careful review (well, the rust-up bit is pretty glaring that I didn't rebuild this recently, but otherwise :) ). Going to address or reply to the various issues on at a time to make sure we get the best result out of this.

[jcvernaleo]

Also, I don't mind squashing the commits when all done if doing this one at a time leads to too many commits (I like a nice clean git history if possible).

[jcvernaleo]

Can't find the comment about it any more, but I have added rust to the build so it completes successfully. Just a few more items to take care of now.

[saurik]

It will help simplify the build process and allow people to build in a common and controlled environment.

So, if we are actually going to go to the trouble of doing this, we should do this "correctly" and have it generate an official reproducible Orchid binary. This is not only using the wrong high-level version of clang, but it is essentially enshrining a build process--bring your own arbitrary compiler binary--that I carefully designed us away from: even the GitHub CI builds on Linux (which this is also duplicating effort from needlessly) don't do anything like this (which is why I named the analogous build regression test there to use the system compiler build-lnx-"bad").

I've started working on a more consistent way of approaching this problem (doing a crossndk sysroot build inside of a Docker container and reusing the abstractions I've recently added for the GitHub CI build). (FWIW, in the future, to the extent to which the request here is "I'd like to have it be easier to run the build in a deterministic Docker environment", I believe it would have been somewhat better to file that first as an issue than to dive directly into a pull request, to avoid what is now feeling like a really awkward situation of "I really don't want to commit this".)

[jcvernaleo]

@saurik the origin of this docker file was that I needed an orchidd binary for use in the Dockerfiles I'm using to run an orchid node and there were no releases containing orchidd. Release v0.9.6 does contain orchidd, but that was just released yesterday. I know that the github actions CI was building releases, but grabbing untagged CI builds seemed like the wrong way to go to me. So most of this work was done before the PR based on my needs at the time.

This was meant as a first step before doing a PR with dockerfiles and docker-compose files for running an entire node (orchidd, openvpn, and geth) after discussions with @nhandler

If you are still interested in it, I'm happy to fix this dockerfile up to match what you would prefer. It was largely done based on what the github actions build was doing at the time I wrote in (back in January I think but I'd have to check to be sure).

I will probably push a few more commits to this either way to deal with the rest of the comments already there since I think it makes for a better dockerfile for whatever time I still need it.

[saurik]

Yeah, I totally understand you needed to compile the project ;P. The issue isn't "you should download a non-release CI build artifact from us", but rather more "the build is designed to be deterministic", this Dockerfile is using clang 8 (which I'm surprised even works as I thought I had added some stuff that broke it after we moved to clang 9), and you even had hacks on the build scripts, none of which are needed if you work with the mechanism instead of against it.

And like, I totally appreciate you wouldn't be in a position to know how to do that; but, even so, adding regex hacks to the underlying makefiles of our own project can't be something we would ever commit as we should just fix the underlying bugs (which, notably, were even able to be there so long because the way you were compiling--doing a kind of casual "default" build for a local computer--isn't what we ever do and don't really want to see much of in production).

Regardless, I've pushed a Dockerfile into srv-docker that can do a "crossndk" build (using the standard ported toolchain we are currently using: the Android NDK r21 LTS from Google) with a CentOS 6 sysroot to generate the exact same binary being produced by all of the other non-"bad" builds (and which shares all of the build environment setup logic I had already abstracted earlier this week). I have also spent the time to add the docker container to the GitHub CI ;P.

FWIW, I totally am excited by the idea of having you work with @nhandler on docker deployment of the actual daemon. My hope is that over time I get around to removing the need for OpenVPN and, maybe even one day, for geth; but, in the mean time, that might make it much easier for users to install the multi-app setup. I just really didn't want to enshrine a bunch of build hacks as "a standard way to compile Orchid" as I put so much care into cross-platform reproduction.