Always install pre-built wheels

Originally written up by @jmbowman over here: https://github.com/edx/edx-arch-experiments/issues/177

There are a few reasons we would prefer to always install Python packages as wheels rather than source tarballs:

• Faster, especially for packages with C or Rust extensions but even for pure Python packages
• Enables us to eliminate hundreds of MB of compilation tools from our Docker images
• More secure, by removing opportunities for arbitrary code execution during installation

However, not all of our dependencies have wheels on PyPI for the versions we use. And of those that do, not all of them have all of the process architectures we would like to support. But this can be worked around. Tentative proposal:

• Document the set of binary formats (OS/architecture combinations) we want to support
• Make sure that all of the Open edX packages get all of the appropriate wheels pushed to PyPI with each release. This will generally be a single universal wheel unless the package contains native code extensions.
• Set up at least one package server for 2U to host wheels for its private code and dependencies which don't have all the needed wheels on PyPI. Ideally there would be a second managed by tCRIL to host just the missing dependency wheels for the benefit of the entire Open edX community.
• Create a repository and Docker image(s) with all of the dependencies needed to build the missing dependency wheels. This could also be used in development to try out new packages with missing wheel variants on PyPI, building them here and then supplying them to the dev environment's devpi instance.
• Update pip configuration to allow installation from the custom package server(s)
• Remove native compilation tooling and development header packages from all the other Docker images.

Some of the benefits could be obtained by instead/also using a builder pattern for Dockerfiles such that the compilation toolchain isn't actually in the images used for development and production, but that leaves some of the security risk, a longer image build time, and occasional hassles in development when installing a new package with a missing binary wheel.

Some package server options:

• devpi - Just for dev environments? Formerly used in devstack.
• AWS CodeArtifact - Easiest for 2U to start using?
• JFrog Artifactory
  Sonatype Nexus

Some tooling that helps build and upload wheels:

• cibuildwheel - Official Python Packaging Authority project
• wheelwright
• multibuild

No repository files, tests, or entry points are named. Start by reviewing the existing pip configuration and Docker images, then determine which package servers, wheel formats, and build dependencies are currently supported. Done means the required wheels can be installed for the documented platforms and compilation tooling can be removed from the other images.