Feature: Allow customized third-party playgrounds. Stateless deployments with playground Docker image.

[rickwebiii]

I have a customized third-party playground that I made by forking this repo and making some changes. The changes are here. I'd like to take many of these changes back upstream with sufficient scrutiny. We made a number of changes, some of which we don't want to upstream because they're specific to our use case, some of which are probably controversial, and some of which aren't.

Top crates (probably uncontroversial)

These changes allow third-parties to fine-tune which crates they do and don't want in their playground. For example, maybe they explicitly only want their company's crates and transitive dependencies.

TODO for this:

• [ ] Allow user to specify how many of the top-N crates you want. Including 0.
• [ ] Allow user to omit cookbook crates.
• [ ] Add a base_directory flag that lets the user override the base_directory computation when writing the manifest file. The default value works fine if you run top_crates from the root of your enlistment.

To accomplish the example scenario, you set N to 0, disable cookbook crates, and add your org's crates to crate-modifications.toml. Easy peasy.

Deployment (probably controversial)

The highlights here are:

• The playground now gets stuffed into a Docker image that you can deploy wherever takes Docker.
• This image uses Docker-in-Docker so it can pull down the desired toolchain images and run them as containers inside the playground container. This requires the --privileged flag with docker run.
• The playground and all toolchain images created in compiler/build.sh have a DEPLOYMENT_ID tag associated with them.
• A playground deployment is playground and toolchain images all with the same tag.
• Deployments are immutable and the playground never downloads toolchain images other than those tagged with DEPLOYMENT_ID. If you want to update the playground with new crates, run a new deployment with a new DEPLOYMENT_ID. This can be done with e.g. a scheduled Github action. No more cronjobs running on deployed instances to fetch the latest toolchains!
• The set of toolchains downloaded by the playground is configurable. Third-parties may not wish to fool with rustfmt, miri, or clippy, as nightly releases of these sometimes don't exist and would break the immutable deployment.
• The deployment/deploy.sh script creates an Elastic Beanstalk application version and fills in the docker image using the specified DEPLOYMENT_ID tag. It then updates the specified environment (i.e. preproduction) to use that application version.

Using Elastic Beanstalk, the playground can auto-scale as load increases, you can have multiple environments, and zero-downtime deployments. However, using EBS is not mandatory and you can take your Docker image to any Cloud provider you want.

I'm not going to put a checklist of MRs under this section until there is discussion about the way this should look.