Add session cache to SslConnector

[pyfqm]

Currently to setting up session cache on the client side requires a bunch of callbacks and unsafe fn. This PR makes it easier by adding an opt-in cache storage to SslConnector, and exposes a simple and safe API (set_use_session_cache set_session_cache_key) for common use-cases. Existing applications will not change their behavior.

The relevant SessionCache code was copied from hyper-openssl.

[pyfqm]

@sfackler Is adding session cache to SslConnector a good idea then? (I explained this in #1041 (comment))

Also cc @alexcrichton: What would be the best way to allow for safe TLS session cache/resumption in the rust ecosystem? Is it idiomatic to "just use unsafe"?

[alexcrichton]

Sorry I don't really know how OpenSSL APIs work in this regard nor what a good interface would be, I'd defer to @sfackler about this.

[sfackler]

I was thinking of this living in a third party crate, at least initially.

[pyfqm]

@sfackler
Er... You want me to create a crate specifically for this? The reality is hardly anyone is gonna use it. Would you perhaps like to put this behind a feature gate?

[sfackler]

If hardly anyone is going to use it, why should it live in this crate either?

[pyfqm]

There may be a lot of people who want to use features like this, but many of them (me included) want them to be in a well-maintained and trusted crate. What is your concern with using a feature gate?

[sfackler]

I'm confused. Are you saying that the number of people who want to use this feature is "hardly anyone" or "a lot of people"?

What's the point of putting this behind a feature gate? My reason in leaning towards wanting it out of crate is to allow more flexibility in figuring out what the right API is. A feature gate is not going to help with that.

[pyfqm]

It's very hard for a new user to gain trust and popularity with one crate. So yes, even if a lot of people want this, hardly anyone is going to want it from someone they don't know.

Oftentimes feature gates come with a document saying "this is unstable and is subject to change." They still allow the flexibility in figuring out the right API. Take, say, rust nightly for example.

[sfackler]

Rust nightly features are not the same thing as Cargo features. I don't want to lie about the semantic versioning of this crate.

[pyfqm]

@sfackler
What do you do when you want to test a small-to-medium sized features? Are we supposed to create a crate to each one of them? To me a crate for each feature seems crazy and would be have much lower discoveribility.

If there's a better way to do this, I'd like to help.

[sfackler]

Like I said before, there aren't really many features like that in this library, since almost everything is a direct equivalent to some OpenSSL function. The one exception is the connector/hostname verification setup which was prototyped out-of-tree: https://crates.io/crates/openssl-verify

[rohitjoshi]

@pyfqm and @sfackler any plan to merge this PR for session cache support?