BUG #19815: 004_sni.pl fails deterministically with OpenSSL 1.1.1 (tests 75 and 86)

The following bug has been logged on the website:

Bug reference: 19815
Logged by: Ben Mejia
Email address: benjamin(dot)arthur(dot)mejia(at)gmail(dot)com
PostgreSQL version: 19rc1
Operating system: RHEL 8.10 (UBI 8 container), x86_64, OpenSSL 1.1.
Description:

The new SNI test src/test/ssl/t/004_sni.pl fails on RHEL 8 with OpenSSL
1.1.1k, which configure.ac documents as the minimum supported version.
Two of its 129 assertions fail on every run. The same source passes on
RHEL 9, and the test has no OpenSSL version guard.

Environment
- RHEL 8.10 (UBI 8 builder image), x86_64, openssl-1.1.1k-18.el8_6
- configure --enable-tap-tests --with-openssl (plus other options)
- source: REL_19_STABLE at fc189eb7508 (after the REL_19_RC1 tag),
which includes commit 4f433025f66 ("ssl: Serverside SNI support for
libpq"); checked against current REL_19_STABLE (0c6e0437110): the
test and be-secure-openssl.c are unchanged by the 40 newer commits
except for 9674c91aeb2 (EXEC_BACKEND/Windows, unrelated to this path)

Reproduce
make -C src/test/ssl check PG_TEST_EXTRA=ssl PROVE_TESTS=t/004_sni.pl

Result (5 of 5 runs identical, about 6 seconds each)
# Failed test 'pg_hosts.conf: connect to default with sslmode=require:
matches'
# at t/004_sni.pl line 333.
# 'psql: error: connection to server at "127.0.0.1",
port 22348 failed: SSL SYSCALL error: EOF detected'
# doesn't match '(?^:handshake failure)'
# Failed test 'pg_hosts.conf: connect to default after failed reload
with ssl_sni off: matches'
# at t/004_sni.pl line 394.
(same message)
# Looks like you failed 2 tests of 129.

Both are connect_fails() calls with sslsni=0 against a server whose
pg_hosts.conf has no default entry, expecting qr/handshake failure/.
The other 127 assertions pass, including the ones that expect
"unrecognized name".

What I checked
- The server rejects the connection as the code intends. Its log has
"could not accept SSL connection: callback failed", and there is no
crash or signal. In sni_clienthello_cb() the no-hostname case sets
*al = SSL_AD_MISSING_EXTENSION and returns SSL_CLIENT_HELLO_ERROR.
- It is not TLS 1.3 specific. With ssl_max_protocol_version =
'TLSv1.2' on the server (the server log then shows
protocol=TLSv1.2 for all 27 connections), the same two assertions
fail the same way.
- It is not a timing race: 5 of 5 runs fail.
- The same source on RHEL 9 with its system OpenSSL 3 passes the whole
test, so the client there does report the expected message. I did
not record that OpenSSL's exact version.

What I do not know
- Whether the 1.1.1 server does not send the alert on this early
ClientHello-callback failure, or sends it and the 1.1.1 client does
not read it before the connection closes. I have not looked at the
traffic.
- Whether any buildfarm animal runs this test with OpenSSL 1.1.1.

Question
Is the expected message in these two assertions meant to depend on the
OpenSSL version? If 1.1.1 should be supported here, should the test
accept the EOF form (as some other tests in this directory accept
alternatives), or should the server behave differently in this case?

I am happy to run further experiments on this setup.