Lift ssl-context coercion to connection-pool fn

[PawelStroinski]

Addresses #728.

[DerGuteMoritz]

Hey @PawelStroinski, sorry for the delay! Responding to the main commit message:

Keeping the client-ssl-context call in http-connection as is,
even though it might seem superfluous considering the code path taken in
the test, but http-connection is a public API, so we have to keep
the call (which for us is a no-op, if we ignore the repeated ALPN check)
even for our case when the protocol is https and ssl-context is supplied.

Hmm I wonder how public that API is really - note how the aleph.http.client has ^:no-doc metadata 🤔 Also, the docstring doesn't explain any of the options and there are no dedicated tests for it either. So IMHO we can consider this an internal API in practice and drop the client-ssl-context call here.

NOTE: This highlights a difference we are introducing here. Previously,
if we specified ssl-context, but the protocol wasn't https, we would just
ignore the ssl-context. Currently, we are coercing it ahead-of-time,
before knowing the request protocol. This could be alleviated by wrapping
the coercion in a delay, so it wouldn't happen until needed. Yet, given
how unlikely this scenario seems, I have doubts whether it'd be worth it.

I agree. If anyone runs into it, they can easily fix it since such a combination of options doesn't make sense to begin with 😅

I slightly dislike the repetition of [:http1] default value,
but since it serves as documentation in http-connection,
I decided to keep it as is rather than to extract it out.

See above - we can get rid of this then, too.

Also, I slightly dislike the repetition of a pattern to call
ensure-consistent-alpn-config and then coerce-ssl-client-context
but it's only now in 2 places, which I think is a better alternative
than adding yet another ssl-coercion layer/wrapping function.
Obviously, we cannot just move ensure-consistent-alpn-config to
ssl-client-context, since ALPN is only for HTTP.

Technically, ALPN can also be used for other purposes but in the context of Aleph's out-of-the-box support, this is true 😄 But as per above, we can get rid of this then, too.

Thanks for your thoughtful notes as always! 🙏

[PawelStroinski]

Thank you for the feedback, @DerGuteMoritz. Certainly, http-connection didn't even have a docstring until a recent (well... relatively, considering long Aleph history) refactoring and the ^:no-doc metadata on that namespace is a good hint regarding the intended usage (or lack of it), indeed. I've updated my PR taking advantage of that fact.