refactor(tls-harness): separate benchmark abstractions

[jmayclin]

Description of changes:

Goal: This PR makes the benchmark crate more generic.

Why: This is being done to allow the harnesses to be reused for our integration testing.

How: This PR separates the bench crate into two separate crates
benchmarks/ contains all of the benchmarks as well as their setup functionality. Note that this includes benchmark-only enums like HandshakeType and CipherSuite.

tls-harness contains the actual generic TLS implementations communicating over shared memory. These are split into

• harness: contains all of the traits and generic structs
• cohort: contains all of the concrete implementations of TlsConnection

Previously, our "benchmark" unit tests were serving as our "harness" unit tests, but this refactor prevents that. So more generic unit tests were added. This specifically included adding a TlsConfigBuilder and TlsConfigBuilderPair. These are deliberately less powerful than the corresponding MakeBenchConfig trait, because it makes them more flexible.

This is preparing for the following dependency structure in the new integration tests:

flowchart TD
    benchmarks --> tls-harness
    integration --> tls-harness

Loading

The largest line diff comes from moving all of the benchmark config setups into their own module under bench_config. I also tried to make the naming a bit less confusing, so now instead of openssl::OpenSslConnection, there is cohort naming, e.g. cohort::OpenSslConnection. This will hopefully avoid confusion from the openssl crate vs the openssl module.

Testing:

Existing transfer and all_handshake unit tests were moved to benchmarks. New unit tests were added for tls-harness.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[jmayclin]

We're returning a string now because the previous CipherSuite definition was only relevant to the benchmarks.

[jmayclin]

Removed because we already have tests for the standard workspace.

[lrstewart]

Do we need to specify "integration" here? If we had interop tests using the same harness, would they have a different new_config method?

[jmayclin]

The reason I added the integration clarification is because the trait gets implemented on the actual struct, and I wanted to make sure that it was distinct from the vanilla "new" method.

// this uses the `new` method from the openssl crate
let builder = openssl::SslContextBuilder::new()

// this uses the method from our trait implementation
let builder = openssl::SslContextBuilder::new_integration_config()

// we could use a more generic name, but I worry that it would 
// get confused with the method from the actual `openssl` crate.
let builder = openssl::SslContextBuilder::new_config()

I would not expect interop tests to use a different new_*_config method.

I'm happy to change the name (although I don't have any ideas that I love), but in practice I don't expect this to be a huge issue because library consumers generally won't be using this method directly.

As an example, consider the following example of a record padding test.

    fn s2n_server_case(pad_to: usize) {
        let mut pair: TlsConnPair<OpenSslConnection, S2NConnection> = {
            let mut configs =
                TlsConfigBuilderPair::<SslContextBuilder, s2n_tls::config::Builder>::default();
            configs.set_cert(SigType::Ecdsa256);
            configs.client.set_block_padding(pad_to);
            configs.connection_pair()
        };

        pair.handshake().unwrap();
        for send in SEND_SIZES {
            assert!(pair.round_trip_assert(send).is_ok());
        }
        pair.shutdown().unwrap();
    }

The test directly configured the SslContext in the configs.client.set_block_padding` call, but it doesn't actually have to setup the raw config.

It always could setup the raw config, but then it would probably make more sense to use the completely idiomatic methods. SslContextBuilder::new(), etc.