Add smol runtime support

[felinira]

This adds support for the smol runtime.

To be precise it's just async-net and its dependants like async-io, because there is no need to pull in the entire smol crate. But for familiarity I think calling it smol-runtime still makes sense.

This does not yet add any tls implementation based on async-io. Currently I am just reusing (read: copy-pasting) the async-std features, but maybe we shouldn't merge it like this. But I am honestly not really sure which one would be preferable here that does not implicitly depend on async-std.

@szgupta @maxdiviant you were interested in the issue, is there a TLS implementation that you would prefer?

See #113

[felinira]

I have done a bit more research on the state of TLS in smol-land.

For rustls I either go with futures-rustls as per the recommendation on the now-defunct smol-rustls. Or we keep async-tls, which "only" additionally pulls in futures-core and doesn't actually depend on async-std.

For native tls I am unsure. There are multiple options:

1. Keep using async-native-tls: I would prefer not to do this, as that defeats the point of a smol runtime based implementation. Also async-native-tls seems to me rather unmaintained. Or is it just complete?
2. Use native-tls directly. This is probably not so difficult, we only need TlsConnector and TlsStream, the async-native-tls implementation is about 240 LOC, but by using Unblock this can possibly go down significantly.
3. Not have any native TLS option for smol at the moment

I tend to gravitate towards 3, which would leave us open to be adding a better-fitting native TLS implementation later.

[sdroege]

For rustls I either go with futures-rustls as per the recommendation on the now-defunct smol-rustls

Sounds good to me

1. Keep using async-native-tls: I would prefer not to do this, as that defeats the point of a smol runtime based implementation

Isn't async-native-tls using the same base crates as smol?

3. seems fine for me for now, whoever needs more can add it later.

[felinira]

Isn't async-native-tls using the same base crates as smol?

Yes and no. They both use async-io nowadays, but smol uses async-net and async-native-tls uses async-std as their async network stack.

The result being that you get the entire dependency tree of async-std pulled in, at which point you can just use async-std.

3. seems fine for me for now, whoever needs more can add it later.

Then I'll throw it out for now.

[sdroege]

They both use async-io nowadays, but smol uses async-net and async-native-tls uses async-std as their async network stack.

Ah I thought async-std is also using async-net.