Improve vibe.stream.openssl support for later OpenSSL versions (1.1.1h, 3.0.x)

[Geod24]

I recently installed Ubuntu 22.04 as my main work machine and Vibe.d didn't build.
Looking more into the module, it's obvious why: The 1.1 support that was added was made in terms of the 1.0 API.
This causes various problems and make it hard to see what piece of code is actually useful.
This is by no mean a full fix, but a good first step (and hopefully inspiration) towards how I believe we can best get there.
Also, as I am on OpenSSL3, it allows me to test that things still work with 1.1 :)

[s-ludwig]

I've made a small correction yesterday - #2650 - and it looks like this is still needed for the changes here(?)

[Geod24]

@s-ludwig : Not really. We're hitting a dub limitation. The tls subpackage dependency on openssl is ~>1.0, but there hasn't been a release to v1 since 2017.
So I thought I'd be clever and update the dependency for openssl config (leaving openssl-1.1 and openssl-1.0 to do their own thing). But obviously that doesn't work, because:

Unresolvable dependencies to package openssl:
  vibe-d:tls 0.9.0-rc.1+commit.298.ge53b865d depends on openssl >=1.0.0+1.0.0e
  vibe-d:tls 0.9.0-rc.1+commit.298.ge53b865d depends on openssl ~>2
  vibe-d:tls 0.9.0-rc.1+commit.298.ge53b865d depends on openssl ~>1
  vibe-d:tls 0.9.0-rc.1+commit.298.ge53b865d depends on openssl ~>1

Which is another instance of dlang/dub#1706

EDIT: The CI failure you are seeing is because we're using Deimos package v1. The issue described above is what happens when I try fixing that issue.

[s-ludwig]

Okay, I just saw that the OPENSSL_VERSION.startsWith("1.1") condition was still there at line 67, but missed the other one further down. But if we want to go down the route of versioning the Deimos packages like that, we'll have to rethink the approach that vibe.d takes. Usually the way this would work would be to depend on >=1.0.0 <3.0.0-0 and then use static if to select the right code path based on the actual version.

The problem is of course the OpenSSL version auto-detection, which currently works transparently. I don't see how that would work without some serious hacks when the dependency version needs to be adjusted accordingly.

But for now I'd say lets get #2650 merged and then decouple the code refactoring from the Deimos dependency issue to keep things going.

[s-ludwig]

BTW, solving the DUB dependency resolution one way or another (where I think that the current approach to resolve versions first and configurations second is really the right one) won't solve the issue of the version auto-detection, we may have to think about a new mechanic for version resolution there.

[Geod24]

For the approach I was taking to work, we would need the Deimos package to have bindings that are compatible with any version we support. That might work for 1.1 / 3.0, but I think that we would have ended up forcing 1.0 users to explicitly select their openssl version. Given the age (and known bugs) in 1.0, I didn't think that'd be a big deal.

[Geod24]

Since this is a cleanup, I'll continue once #2658 is in.

[Geod24]

So most of my fixes are now directed directly at Deimos, and this can go. I'll submit the relevant bits individually.