Potential memory issues when slow HEC responses

[rquinio1A]

In another project using splunk-library-javalogging, it has been reported that if HEC endpoint is slow to answer because it's in bad shape, then this can lead to OutOfMemory on the client, because log event objects are not garbage collected on the client.

In sync mode, slow logging may slow some application threads, but there is no max "in-flight" log event batches
In async mode, using quarkus.log.handler.splunk.async and quarkus.log.handler.splunk.async.overflow=discard could mitigate the issue, if Quarkus starts droping logs after the queue limit has been reached. However the dequeing is probably not limited by anything today, so it could be the same problem.

If the number of "in-flight" batches is over a certain limit, we could drop log events/stop dequeing, rather than adding them into in a new batch.
This would require to have counters over in-flight vs completed log events, cf #57
cf splunk/splunk-library-javalogging#265
cf splunk/splunk-library-javalogging#98