Suricata

Investigation shows that `http_state->conn->transactions` does not shrink as `VecDeque` when one transaction should get removed (the transaction is freed and replaced by NULL)

Need to think on this first...

I thought I had a Suricata-only fix, but libhtp uses htp_list_get(connp->conn->transactions, connp->out_next_tx_index);
and tx->index = htp_list_size(tx->conn->transactions);

So, I may have a Suricata+libhtp fix...

So, I see 2 sub tasks here :
- do not have an ever growing list of HTTP1 transactions per flow
- configurable limit for maximum number of live HTTP1 transactions per flow
The current MR is for the first one

Another thing could be to have a configurable limit for maximum number of live transactions per flow whatever the app-layer protocol

The slowness of DetectRunTx when there are multiple live transactions per flow is to be tracked on #6299

See also https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62416&q=label%3AProj-suricata

https://github.com/OISF/suricata/security/advisories/GHSA-q33q-45cr-3cpc