quic-hq-interop: Allow for retries if we've reached our max stream limit

quic-hq-interop: Allow for retries if we've reached our max stream limit

Several servers defer the sending of max stream frames.  For instance
quic-go uses a go-routine to do the sending after sufficient existing
streams have finished, while mvfst seems to wait for all outstanding
streams to be closed before issuing a new batch.  This result in the
client, if all streams are in use, getting a transient NULL return from
SSL_new_stream().  Check for the stream limit being reached and allow a
number of retries before giving up to give the server a chance to issue
us more streams.  Also dead-reckon the batch count of streams we use in
parallel to be 1/4 of our total number of available streams (generally
hard coded to 100 for most servers) to avoid using all our streams at
once.  It would be really nice to have an api to expose our negotiated
transport parameters so that the application can know what this limit
is, but until then we have to just guess.

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26527)