Build a container for miri tests

[jsha]

Right now we're getting this error for the miri tests:

error: component 'miri' for target 'x86_64-unknown-linux-gnu' is unavailable for download for channel nightly
Sometimes not all components are available in any given nightly. If you don't need the component, you can remove it with:

    rustup component remove --toolchain nightly --target x86_64-unknown-linux-gnu miri

We should build a container with a given version of nightly that we know has the miri component, so we're not vulnerable to breakages like this. That would also be beneficial for build times, since right now we build some things for the miri test job, and that's slow.

[djc]

Given the UB found in #195, probably good to prioritize this?

[jsha]

Good to prioritize, but worth noting that Miri wouldn't have caught the UB in #195. That UB occurred at the FFI boundary, but Miri only handles Rust. To catch it we would have needed Rust tests that explicitly exercised the case of creating an invalid enum to pass to rustls_error.

It looks like Miri now provides instructions on how to include it in CI while accounting for the problem that it doesn't exist in all nightly builds: https://github.com/rust-lang/miri#running-miri-on-ci

To properly exercise our code, under Miri, we'll want to write a bunch more unittests on the Rust side. It would also be good to have an integration test that acts like client.c / server.c. However:

Miri runs the program as a platform-independent interpreter, so the program has no access to most platform-specific APIs or FFI. A few APIs have been implemented (such as printing to stdout) but most have not: for example, Miri currently does not support SIMD or networking.

Fortunately the read_tls / write_tls interfaces in rustls don't require writing to an actual network, so we can just simulate a network connection with a pair of buffers.

[jsha]

Done in #199. We didn't wind up needing to create a container. 🎉