This story would be about refactoring the code related to crypto and prepare the path for the crypto future of rama. Follow up stories can continue the work started here. There are two aspects to this:

1. Regards to tls, we drop the attempt of finding one unified API to rule them all and instead respect that the rustls integration has a different purpose than that of boring. For all the standard common use cases Rustls is fine. And so it wil have a nice working client connector and a nice transport layer-service to accept streams on server sides. But that's pretty much where that one ends. Boring will be used in case you need a tight grip on the controls, have all kind of special needs, want to do advanced stuff etc. In this story we'll still work with the cloudflare bindings but in a future we'll want to provide our own rama-tls-boring crate. As part of this task you can already create this crate (dummy-style, see rama-socks5 for an example) to already reserve the name next time we publish an alpha version.
2. Secondly, we affirm that crypto is more than just tls. So far we didn't have the luxary to think about that, but now with the http(s) stack shaping up we can think about that a bit more. Data verification, encryption and hashing is a thing and used for a lot more than just tls. E.g. JWT support is an example for that. As such it would make sense to perhaps have a rama-crypto crate where we would also house crypto primitives and expose crypto backends as well. Or perhaps we do not need such a crate and we could just expose jwt in future directly from within rama master crate somewhere.

• we would need to think on how this relates to tls though. It's confusing in the crypto space in general. E.g. libs like boringssl and openssl are really focussed on SSL/TLS, but at the same time they also come with many related cryptographical algorithms and tools. This makes me not entirely certain what to do with crypto backends if we also have a rama-crypto crate. E.g. do we also expose boring there? Or instead use rama-tls-boring if the boring feature is enabled? or perhaps only have it in rama-crypto and have rama-tls-backend use that? All choices feel weird in their own way.
• what is however more certain that it does make sense that we should have:
  • easy support using our backends already available for our tls support for: encryption, signing, hashing and random data
    (e.g. boring in case that's anyway available)
  • jwt support as it's pretty common for a lot of projects to need that, so it might make sense to expose that. That's not for this story. But I did start work on https://github.com/Keats/jsonwebtoken to have that crate be able to work with other crypto backends, which would allow us to embed that crate and re-export it, but reusing the same crypto backend (depending on the feature) that we already use for tls. Keeping the dep tree of the rama user small.

(2) will have less focus in this story then (1) but I would like that the path regarding this all becomes a lot more clear after we resolve this issue. (1) is however where the focus should be. It will result in some code removal and simplifying certain bits. And all the advanced / low-level controls will move to boring instead of something generic.

Not sure how this will impact rama::net::tls and rama::tls... that will ahve to be figured out. In one hand I think it wil make it possible to keep things a lot easier and just use the crypto backend API's directly instead of abstracting it away. At the same time I do like how easy to use the abstraction layer in the middle is to setup a lot of common stuff... So there's some thought that need to be put here. E.g. there's something to be said with how simple stuff like

works compared to the more complicated matters that it controls under the hood...