Look into breaking down the user's container into more incremental builds

[atheurer]

Right now we don't reuse much when building a new container. We start with the base OS (userenv), and then we add everything we want, then commit this image. We might be able to have more commits between the base OS and the final product. This may help in building another container which has slightly different requirements (perhaps one less tool).

It might be a good idea to build a container with just the benchmark requirements, then commit this (with a md5sum as the tag), then build on top of that by adding user's tools, then commit again (with another md5sum). When a user wants to run the same benchmark (and same userenv, same benchmark version, etc), but want a different set of tools, they at least get to use the intermediate container (with the benchmark), then add their tools for their final container image.

[atheurer]

Thinking more about this, we could just build userenvs with their own base requirements in their userenv.json. That alone would probably eliminate a lot of rebuilding, since all users would then be able to start with a image that is the base userenv + the userenv requirements (instead of getting the base userenv image and installing those requirements). We should still use the md5dsum calc to uniquely identify these images.

So, when a user wants to build a new image, they can do a search for md5sums in this order:

1. get md5sum for all requirements (userenv, benchmark, tools), if image is found, use it, and exit.
2. get md5sum for all requirements but tools, if image is found, start with this and add tools, upload image, then go to step 1.
3. get md5sum for all requirements but tools and benchmark (userenv plus whatever rickshaw adds that is not bechmark/tools), if image is found, start with this, add tools, upload image, then go to step 2.
4. get md5sum for userenv (base requirements), if image is found, start with this, add base rickshaw reqs, upload image, then go to step 3.