Enhance http3 demo client to support features we use in curl for interop testing

[nhorman]

Recently, curl reverted support for OpenSSL as a quic stack, which broke our interop testing. Short term we can use an older version of curl to work around this, but longer term we need to find another command line http3 client to use that supports our quic stack for the purpose of interop testing.

Our ossl_http3_demo client is likely pretty close, but is missing some features. Most notably:

1. it needs to support configurable paths to request (not just "/")
2. it needs to support being able to submit multiple requests on a single connection
3. it needs to allow for writing results to a file

If we get those enhancements in place, we can stop using curl entirely for our http3 tests and this won't be an issue anymore.

[Sashan]

would ssl_poll_perf work here? I'm able to use the client against tquic server from tencent. Run server:

cd $TENCENT_SRCS/target/release
perl -e 'print "A" x 1024' > 1024.txt
./tquic_server -c ~/work.openssl/openssl/test/certs/servercert.pem -k  ~/work.openssl/openssl/test/certs/serverkey.pem

run ssl_poll_perf client from perf tools:

# ./ssl_poll_perf -m c \ # enable client mode only
                           -c 10 \ # create 10 connections
                           -a 0   \ # use ALPN for HTTP 0.9 
                           -b 10 \ # create 10 bidirectional streams
                           -u 0   \ # 0 unidirectional streams as tquic server is no able to work with them
                           -w 0  \ # do not add any request body (0 request body payload)
                          http://127.0.0.1:4433/1024.txt # URL to download
client_thread
        tx: 1500
        rx: 102400
in 0.2286 secs

command above creates 10 QUIC connections, each connection opens 10 streams, each stream downloads 1024.txt, so there will be 10 x 10 x 1024 bytes downloaded.

I have not tested it with other servers. But it feels like a good start.

[nhorman]

It probably is a good start @Sashan , but the requirement here is for http3 transfers, not http1.0 transfers. The quic bits are probably all there, but we would need to integrate nghttp3 with that tool.

I've actually got this working with our ossl-nghtt3-demo at this point and will be posting a patch for it shortly. It has the advantage of already using nghttp3, it just needed to have the ability to handle multiple streams integrated with it, which (based on my attempts to understand how nghttp3 works) seems like the easier lift.