Set up regression benchmark for scalar performance

[kaukabrizvi]

Resolved issues:

N/A

Description of changes:

To integrate performance benchmarking into the CI pipeline for s2n-tls, this PR introduces the structure for regression harnesses that benchmark essential TLS connection components. This PR specifically includes the following:

• Config Creation (test_set_config): Builds a new s2n-tls config with a security policy, host callback and certs
• RSA Handshake (test_rsa_handshake): Measures the performance of performing a handshake with a pre-set config.

Crabgrind is used to call the Valgrind client request interface, enabling selective benchmarking only for the desired code regions within each harness.

Call-outs:

• Reverting some changes in PR #4623: Certain structs defined in bindings/rust/s2n-tls/testing are reverted to be public by enabling the unstable-testing feature. This allows the regression module to import these with the feature enabled. This struct facilitates setting up connections like the RSA handshake harness.
• Recursive cargo test: To run the tests via valgrind the testing library calls on each test recursively by setting an environment variable flag. This enables running tests without performance capturing enabled via cargo test and with performance capturing enabled with VALGRIND = true cargo test
• Separate functions: To measure fine-grained parts of typical TLS connections, these harnesses are separated into distinct functions despite some overlap. Cachegrind's limitations in dumping stats at specified points necessitate creating a new config in test_rsa_handshake rather than combining everything into a single harness.

Testing:

This addition does not change any existing functionality.

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

[camshaft]

Does this work? I'd prefer to have this crate in the existing workspace.

[kaukabrizvi]

Yes, it works and enabling debug information is necessary for Cachegrind to accurately identify where instructions come from using the symbols. Setting debug in profile.release ensures that we retain the necessary debug information for detailed analysis while also tracking optimization in release. We can do that here or in the existing workspace but there is more room for discussion about where the crate should live.

[camshaft]

Sorry I should have been more specific. I thought you could only specify profile overrides at the workspace root, not individual crates in the workspace. If this isn't in the main workspace it needs a

[workspace]
members = ["."]

[camshaft]

That being said... I would prefer that it is in the main workspace so these tests are run as part of the main test suite. Otherwise they get a bit neglected and people only find out they're broken in CI.

[kaukabrizvi]

That makes sense, it can run as part of the regular pre-PR workflow for devs once diffing is enabled by comparing local to the HEAD-1 commit. I'll make these changes in the next revision.

[kaukabrizvi]

In trying to add these tests to the existing workspace I ran into an issue where crabgrind can't compile due to an unresolved import 'std::ffi::c_char'. This type was added to std in Rust 1.64.0. Since the bindings/rust workspace requires the 1.63.0 rust-toolchain, this import doesn't resolve. We can either:

1. Bump the rust-toolchain version: Local development might miss breaking changes specific to the underlying Rust 1.63.0 bindings.

2. Include the regression test in a separate crate: Regression tests will be isolated from the main test suites.

If there are any other potential solutions I might have missed, please let me know. However, given these options, I believe it makes sense to develop the regression tests in a separate crate to avoid that sort of disruption to the bindings development process.