SDKs: buffer outgoing messages to some fraction of the incoming-queue-length limit

This will require:

• Exposing the incoming-queue-length limit, which is likely easiest done via an HTTP route.
• For each SDK, modifying it to:
  • When opening a connection, fetch the incoming-queue-length limit and divide it by two to get max_in_flight_requests. If this request fails, log the error and default to 1024.
  • Keep an internal queue of outgoing requests and a counter of the number in flight.
  • When sending a request, if the in-flight counter is greater than max_in_flight_requests, log a warning and put the request in the queue. Otherwise, increment the in-flight counter.
    • When sending a request with the NoSuccessNotify flag, do not increment max_in_flight_requests, but do use the queue if max_in_flight_requests is already reached.
  • When receiving a response, if the queue is not empty, pop from it and send that request. If the queue is empty, decrement the in-flight counter.
    • If the response is a failure response to a NoSuccessNotify request, skip this.

Start by locating the HTTP route for the incoming-queue-length limit and the connection-open, outgoing-request, and response-handling entry points in each SDK. Done means every SDK fetches the limit with the stated fallback, bounds in-flight requests with a queue, and handles NoSuccessNotify responses as specified.