fix(http): large prometheus metrics responses split across multiple chunks

[amunra]

Change

This is a minor fix for the way that we handle prometheus metrics.
Prometheus metrics are exposed as the /metrics URL on the http-min port.
Currently we don't report enough metrics to cause a problem, but if we were to expand the amount of metrics we produce we'd run out of the fixed buffer size (defaults to 1MiB).

The buffer size is fixed, because we return responeses with the "chunked" transfer encoding (HTTP 1.1).

This PR also includes test enhancements that perform parallel requests to the Prometheus endpoint.

Implementation

This fix first encodes all the metrics to a separate buffer, then copies that buffer to as many chunk as required.

The serialization buffer, along with a written counter tracking how many bytes got copied to http chunks is tracked inside RequestState objects. To avoid continuously calling malloc and free for potentially larger buffers, these objects are pooled and reused.

The pool is shared across all instances of the PrometheusMetricsProcessor (one per worker).
This avoids allocating multiple large buffers in case of sparse requests (which is the default use case for the /metrics URL).

Additionally, the Scrapable metrics interface has been updated from using CharSink to DirectUtf8CharSink which allows borrowing the writable buffer as a C questdb_byte_sink_t* and adding metrics from native code.

[amunra]

Merged latest changes. This PR is ready to be reviewed again.

[ideoma]

[PR Coverage check]

😍 pass : 80 / 80 (100.00%)

file detail

	path	covered line	new line	coverage
🔵	io/questdb/cutlass/http/HttpResponseSink.java	5	5	100.00%
🔵	io/questdb/cutlass/http/HttpServer.java	4	4	100.00%
🔵	io/questdb/std/str/DirectByteCharSink.java	5	5	100.00%
🔵	io/questdb/cutlass/Services.java	4	4	100.00%
🔵	io/questdb/cutlass/http/processors/PrometheusMetricsProcessor.java	62	62	100.00%