When an HTTP(S) client performs a session with a server that needs more than one round trip,
as is typical for instance when requesting a certificate and confirming its reception and acceptance,
it makes much sense not to close in between the underlying TCP connection or even TLS connection.

Quoting from the current HTTP RFC 7230, section 6.3, https://tools.ietf.org/html/rfc7230#section-6.3:

HTTP/1.1 defaults to the use of "persistent connections",
allowing multiple requests and responses to be carried over a single connection.
The "close" connection option is used to signal that a connection will not persist after the current request/response.
HTTP implementations SHOULD support persistent connections.
...
If the received protocol is HTTP/1.0, the "keep-alive" connection option is present, the recipient is not a proxy,
and the recipient wishes to honor the HTTP/1.0 "keep-alive" mechanism, the connection will persist after the current response;

So far the basic HTTP client integrated in OpenSSL does not support this
(and neither the very primitive HTTP test server in apps/lib/http_server.c)
although it would be good to have in particular for the CMP implementation.

As a prerequisite to implementing this, it will be necessary to adjust the HTTP API
documented in OSSL_HTTP_REQ_CTX.pod and OSSL_HTTP_transfer.pod
such that the OSSL_HTTP_REQ_CTX can be reused for further requests.

After doing so, it would be pretty straightforward to extend the state machine
with a flag indicating whether client and server side agree on keeping the connection.