⭕ Add full CircleCI configuration

[acfoltzer]

This patch ports our existing Github Actions CI to CircleCI, which allows us to test programs that use the userfaultfd syscall on Linux. Also, we're paying CircleCI to use their big machines and Docker layer cache, so CI overall will be much faster.

A significant change from the Github Actions setup is to revert to a single build job, rather than having a proliferation of smaller jobs. The latter approach was necessary to achieve good performance with Actions, but the way CircleCI's Docker caching works, the single job is much more cost effective.

These jobs cache the Cargo-generated /target directory for branch builds, which substantially helps run times. Cargo is pretty aggressive about rebuilding when files, environment variables, or moon phases change, but the cache is completely disabled for master builds. This will help to catch any bugs that might arise only from a completely fresh build context.

This also makes a couple of tweaks to eliminate CI cruft:

• Download a binary distribution of binaryen rather than building it from scratch in the Docker image.

• Parameterize the binary test scripts (signature.sh and objdump.sh) by release mode, so that we can test both with the same /target populated.

• Stop testing the cargo deb packaging step, and remove the cargo-deb install from the Dockerfile. As far as we know, this packaging is not currently used by anyone.

[fst-crenshaw]

Thanks for this cautionary comment.

[acfoltzer]

One important limitation I just noticed: the CircleCI build only runs on the commit of a PR's branch (what GH Actions labels the push), it does not automatically run on the merge commit (what Actions calls pull_request).

This raises the possibility that if a PR is not up to date with master, all of the CI might go green for a PR, we'll press the big green button, and the resulting merge commit into master will fail. The silver lining is that it will fail, since CircleCI runs on all commits by default.

It looks like there's an open (and popular) feature request to add testing on synthetic merge commits to CircleCI directly: https://ideas.circleci.com/ideas/CCI-I-926

This is also another case where using bors would help, since bors creates staging commits that are never behind master. Maybe it's time to set up bors for this repo?