Structural Refactor

[stevefan1999-personal]

This PR revamps the whole structure of the crate, making it more modular and reducing code spaghetti and feature implications. It's a significant overhaul that addresses several long-standing issues and paves the way for future improvements.

One of the key benefits of this restructuring is that it makes flexible feature inclusion possible in the future. For example, you can choose to only include AES crypto suites or remove NIST curves to customize it to your needs. This level of customization is very useful for resource-constrained systems such as embedded devices that can't afford large code sizes.

The modular approach also improves maintainability and readability of the codebase. By breaking down the monolithic structure into smaller, more focused modules, we've made it easier for developers to understand and work on specific parts of the crate without getting lost in unnecessary complexity.

Additionally, this restructuring sets the stage for easier integration of new features and optimizations in the future. The cleaner architecture will allow us to add or modify functionality with minimal impact on existing code, reducing the risk of introducing bugs or breaking changes.

[stevefan1999-personal]

After testing it through a private functional test, I would say the effort to make this refactor really pays off. It's been a game-changer for my development process. Before that, I had to include every suite possible, which was a real headache and made the codebase unnecessarily bloated. Now, I can just choose whatever crypto suite I want, say for my ESP32 code now. It's given me so much more flexibility and control over my projects.

While I didn't get a chance to run a real test on the ESP32 hardware itself (which is definitely on my to-do list), I used the following setting in my Windows binary test to simulate the environment:

rustls-rustcrypto = { version = "0.0.2-alpha", default-features = false, features = [
    "alloc",
    "chacha20poly1305",
    "kx-p256",
    "ecdsa-p256",
    "pkcs8"
] }

This is a bare-minimum dual TLS1.3/TLS1.2 compliant setting, using only TLS13_CHACHA20_POLY1305_SHA256 and TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (for TLS1.2). But if I ran only TLS1.3, it would shave off about 300KB from the binary, down from 1MB to 713KB (30% binary size saved!). That's a scary amount. It's wild to think about how much space these security protocols take up.

This approach allowed me to get a good feel for how the refactored code would perform in a more constrained environment like the ESP32. The results were promising, showing improved efficiency and reduced overhead. It's really exciting to see how this change could potentially optimize performance on embedded systems.

I mean, 300KB might not seem like a lot in today's world of gigabyte-sized apps, but when you're working with embedded systems or trying to optimize for performance, every kilobyte counts. And let's be real, the fact that dropping down to only using TLS1.3 and just one suite saves that much space is kind of mind-blowing. It really makes you wonder about the trade-offs between security and efficiency, especially in resource-constrained environments. I guess that's the price we pay for keeping our data safe in transit, right?

PS: The environment is simulated using Rustls unbuffered API, which is for running in an embedded, no_std but alloc available environment. Together with this provider being no_std friendly, this is probably the first publicly-maintained provider that could run on MCUs officially.

[tarcieri]

@stevefan1999-personal it looks like there are conflicts with master that need to be resolved