Bugfix/2530 atomic requests buffer size

[harshal24-chavan]

Fixes Issue #2530

Description:
Replaced the std::promise/std::future implementation in requestsBufferSize() with an std::atomic<std::size_t>. Previously, calling this method from outside the event loop forced a cross-thread future resolution, blocking the calling thread entirely and preventing efficient async connection pooling.

This PR centralizes the requestsBuffer_ mutations (push_back, pop_front, erase) to safely track the queue depth natively within the background thread. Reads now use std::memory_order_relaxed for zero-overhead, non-blocking execution.

Testing Performed:

• Passed the full existing CTest suite.
• Formatted via clang-format-17.
• Wrote a standalone local test to flood the client with delayed requests. Verified that the atomic counter correctly tracks the enqueuing, popping, and erasing of requests natively in the background thread, while allowing the main thread to poll requestsBufferSize() instantly in O(1) time without deadlocking.

[an-tao]

Thanks for the PR.

The idea of avoiding the blocking promise/future path in requestsBufferSize() makes sense. However, I don’t think this fully solves the problem yet.

requestsBufferSize() currently only tracks requestsBuffer_. Requests that have already been sent but have not received a response are stored in pipeliningCallbacks_, so the method may return 0 even when the connection is still busy. This is especially important for long-polling requests or when pipelining is enabled.

For load balancing among multiple HttpClient instances, I think the reported load should probably include both pending buffered requests and in-flight requests, e.g. something like:

requestsBuffer_.size() + pipeliningCallbacks_.size()

or we should introduce a separate API with clearer semantics.

Could you please update the PR to account for in-flight requests as well, and ideally add a test covering this case?

[harshal24-chavan]

Understood! I'll take a look at how pipeliningCallbacks_ works and figure out a solution to track both & add a test case.
Thanks for pointing this out!

[harshal24-chavan]

PR Summary:

• Added outstandingRequests() to report total connection load (buffered + in-flight callbacks).
• Added atomic counter (pipeliningCallbacksSize_)
• Used inline increments for the strict std::queue to avoid boilerplate, but preserved helpers for requestsBuffer_ to guard std::list mutations.
• Added integration tests (HttpClientOutstandingRequests.cc)