Docker toolchain

[SafariMonkey]

This PR adds a docker image specification that can be used to build rust binaries for the reMarkable. It works on Linux (untested on OS X) and only requires Docker and make as dependencies.

Before this PR, a user compiling on ubuntu 16.04 would need to perform all the steps listed here except for starting a VM. On 18.04, I was unable to cross compile successfully at all due to glibc versioning, despite much effort. However, with this PR merged, any linux user with docker, make and reMarkable ssh set up can do:

git clone https://github.com/canselcik/libremarkable
cd libremarkable
make run-docker

and see the demo running on their device. They can also copy the make target for compiling their own programs.

To make it easier to build in docker and deploy directly, the run target is now an alias for examples and deploy-demo. There is a new target, run-docker, which builds the binary in docker instead of locally before deploying. This pattern can be applied to other deployment targets if desired.

It also makes two changes that were needed for a successful build on latest nightly: pinning atomic to 0.4.0, and removing the const_size_of feature gate (as it appears to have been removed)

A couple technical notes:

• It's slower, but not that much.
  • The first build of the docker image and binary are expected to take some time. However, all three slow steps are cached:
    • The docker build is cached by docker, and should rarely change
    • The rust registry is mounted in a volume, and thus persisted across builds
    • The target folder is on the host, so the compiler cache is persisted across builds.
  • Some sample build times on my machine:
    • First build, no caches: 7m17.09s
    • Build only changing demo.rs: 0m8.28s
    • Build with no changes: 0m3.24s
• Docker layer cache may cause the rust toolchain to go out of date. A couple potential workarounds:
  • periodically build the image with cache disabled to force a redownload
  • invalidate the cache by adding a file containing the date
• Mounting and using the directory without affecting permissions requires setting the UID and GID of the user inside the container to the owner of the directory. For now it is set to the UID and GID of the user running the make command, which should work in most cases. This also means the image is specific to the UID-GID combination, and can't easily be distributed. There are methods that solve that problem, like what redis does.

[canselcik]

This looks great, thank you for your contribution @SafariMonkey. I appreciate the thoughtful write-up as well.

I will test locally in a few hours and then merge.