Enable TLS-PSK auth

[Elzor]

If we need only TLS-PSK authentication (without additional certificates, sni, etc) cowboy returns {error, no_cert} for cowboy:start_tls/3. Actually this is regular way to use PSK, althouht it's rare.
Sample config for this case:

%{
  num_acceptors: 4,
  max_connections: 1024,
  socket_opts: [
    {:protocol, :tls},
    {:port, 12123},
    {:handshake, :full},
    {:ciphers,
      [
        %{cipher: :aes_256_gcm, key_exchange: :psk, mac: :aead, prf: :sha384}
      ]},
    {:user_lookup_fun, {&Hota.Api.Http.PskLookup.lookup/3, <<>>}}
  ]
}

[essen]

Please add test(s) to acceptor_SUITE. You can make it look similar to the SNI tests.

[Elzor]

@essen Thanks for review and your comments. I've made alphabetical order for options and added two tests for PSK.

[essen]

@juhlig @Maria-12648430 Can you please review? Thanks!

[juhlig]

Oh... I never noticed the review request =^^= SSL/TLS is really not my home ground, but in any case, the tests on buildkite mostly failed in just the tests added by this PR, so...

[essen]

@Maria-12648430 I think merging this wouldn't be a problem for #324 (minus a potential rebase), since we move forward when the option is there, and if using TLS 1.3 we then reject the option. Correct?

[Maria-12648430]

@Maria-12648430 I think merging this wouldn't be a problem for #324 (minus a potential rebase), since we move forward when the option is there, and if using TLS 1.3 we then reject the option. Correct?

Hm, I'm not sure. There is some kind of clash here, yes. If the user_lookup_fun option is present, we proceed here, then (with #324) iff TLSv1.3 is the only protocol version used, it is erased again. OTOH, user_lookup_fun is not usable with (only) TLSv1.3, anyway, and currently (without #324) the listener won't start at all but fail with an option dependency error.

[essen]

Right we remove not reject. So we would end up with a potentially confusing error then I think. But I'm not sure we should do anything about it.

[Maria-12648430]

I have no idea what would happen if user_lookup_fun was used in a setup containing TLSv1.3 and, say, v1.2 (which ssl and subsequently ranch_ssl allow)), and the actual connection was then made with TLSv1.3 ^^;;;

[Maria-12648430]

Right we remove not reject. So we would end up with a potentially confusing error then I think. But I'm not sure we should do anything about it.

The possible outcomes for [{user_lookup_fun, ...}, {versions, ['tlsv1.3'}] are...

• without Disallow unsupported options for TLSv1.3 #324...
  • on OTP<23, it will be accepted (listener starts), but the option will (probably) be ignored by ssl
  • on OTP>=23, it will be rejected (listener start fails with option dependency error)
• with Disallow unsupported options for TLSv1.3 #324, the option will be removed and a warning will be logged, but the listener starts. So, the behavior is somewhat like OTP<23 without Disallow unsupported options for TLSv1.3 #324, but plus the warning

[essen]

OK good enough.

[essen]

Merged, thanks!