wasi-tls: Add OpenSSL backend

[badeend]

Wasmtime currently supports two wasi-tls providers: rustls & native-tls.

Having multiple backend implementations in a single place helps with being able to quickly iterate on the WIT interface and validate that we're not codifying some rustls-specific behavior/feature into the spec.

@rvolosatovs is looking at implementing wasi-tls for Python. But as predicted, native-tls is quickly showing its shortcomings. For example: it can't read the negotiated TLS version, which is needed to implement Python's SSLSocket.version().

This PR adds a third backend: OpenSSL. The openssl crate exposes a much larger API surface than native-tls does and will most likely be enough for wasi-tls' future needs.

Depending on how restrictive the wasmtime-wasi-tls-nativetls implementation ends up being, we might consider removing it altogether. For the time being it still works fine, so I've kept it.

What matters to me is that we can demonstrate having two distinct TLS implementations working on all the three major platforms. As long as that criteria is being satisfied, I don't think it really matters whether that's rustls+nativetls or rustls+openssl.

[alexcrichton]

Thanks for this! (also thanks for wrangling CI here...)

For the remaining checks -- could you publish a placeholder crate and invite the wasmtime-publish github user to the crate? I'll accept the invite and add the wasmtime-publish github team too.

For the vets, would it be possible to update the lock file to retain the slightly older versions of openssl/openssl-sys? Or are the new versions required? (not hard to vet but if it can be deferred might as well)

[badeend]

(also thanks for wrangling CI here...)

It only took 14 attempts 🤪

could you publish a placeholder crate and invite the wasmtime-publish github user to the crate?

I've created the crate and added wasmtime-publish. Did you get the invite?

would it be possible to update the lock file to retain the slightly older versions of openssl/openssl-sys?

Yes! See latest commit. That still leaves tokio-openssl & wasmtime-wasi-tls-openssl of course

[alexcrichton]

Did you get the invite?

I did indeed! Should be updated now too.

Looks like a cargo vet part remains? Otherwise r=me

[alexcrichton]

Oh, to clarify, @badeend would you be ok adding the config recommended by cargo vet to get that clean? We try to have maintainers do the actual vets but this is just an infrastructure thing so it's fine for anyone to edit the files

[badeend]

this is just an infrastructure thing

Just to verify: aside from the placeholder wasmtime-wasi-tls-openssl crate, this PR is also adding a brand new dependency on tokio-openssl which is not under control of the BA. You want me to vet that as well?

[alexcrichton]

Oh sorry I forgot about that, I was going off the CI failure as:

ERROR   × There are some issues with your policy.audit-as-crates-io entries

Error:   × Some non-crates.io-fetched packages match published crates.io versions
  │   wasmtime-wasi-tls-openssl:42.0.1
  help: Add a `policy.*.audit-as-crates-io` entry for them

and I suspect that it'd later complain about tokio-openssl if that were resolved. If you wouldn't mind resolving this error about wasmtime-wasi-tls-openssl I'll add the vet for tokio-openssl