Testing strategy: C, Rust, Miri

Right now we have a small C-based integration test (client.c and server.c), and a few Rust-based unittests. I want to expand both our unittest and integration test coverage, with unittests first.

One open question: To what extent should our tests be in Rust vs C?

My initial thinking was that the tests should be in C, since that is what will ultimately be using the library, and we can catch issues that only occur on the C->Rust boundary. More recently, thinking about Miri, I realized we can only get Miri coverage for tests written in Rust. That's a strong reason to write tests in Rust.

However, in #208 I realized that most non-trivial rustls operations will wind up invoking FFI code in *ring*, which causes Miri to fail. Unfortunately I think that means we can't use Miri for most of our test, unless we develop a way to mock out *ring*, which seems unlikely.

The tooling for unittests in Rust is so much more convenient that even with the finding above, I'm still leaning towards writing most of the tests in Rust (and expanding on / improving the integration test in C). Thoughts @djc @tgeoghegan @icing?

Start by reading client.c, server.c, the existing Rust unit tests, and the discussion in #208. Establish the Rust-versus-C testing strategy, then define the unittest and integration coverage to add, including whether Miri can be used given the ring FFI boundary.