Haproxy connection pools keep minimum number of connections

We have an outbound path we are trying to use that is latency sensitive. The remote site is about 100ms away, so the TLS handshake is quickly adding to the total time for a transaction. Our idea was to use haproxy as an egress controller to help reuse these connections, so we didn’t have to do a seperate handshake for each. The remote side does not yet support http\2, but they are working on it.

This seems to work great when things are busy. however, when there is little activity (a transaction every few min) each one creates a new connection. It does not seem to keep a ‘minimum’ number of open and ready connections.

We have a backend configured for haproxy 2.6 like so: (for testing, i’m not verifing SSL, but would for production)

   backend outgoing-test
      log global
      #using examples from https://www.haproxy.com/user-spotlight-series/haproxy-as-egress-controller
      timeout http-request  50s
      timeout http-keep-alive 30s
      timeout queue 0s
      http-request set-header Host api.example.com
      http-request replace-path /outgoing-test/(.*) /\1
      #should only use 20 connections max
      fullconn 20
      http-reuse aggressive
      server outgoing_test api.example.com:443 resolvers mydns maxconn 20 sni str(api.example.com) ssl verify none alpn h2,http/1.1 pool-purge-delay 30m

Is there a way to have haproxy persist a minimum number of connections with http keepalives, so its ‘ready’ when needed?
We use haproxy heavily for inbound, so it was natural to try with this to start… but if this is not realy what its for, can someone recommend a tool to use for outbound that could help? I guess conceptually, i am looking to do something similar to what PGBouncer does for Postgres connections, but for outbound TLS to get around the latency and time of using new connections.