Test if adding work queue to javascript SDK improves perf with large numbers of user requests

[cprice404]

When tuning the javascript SDK, it became evident that the number of concurrent requests that are queued up has a significant impact on performance. (For example, if you go from 100 concurrent requests to 5000 concurrent requests, the throughput remains about the same but the latency goes up on the order of 100x.)

It may be the case that the polling for responses to all of the outstanding requests at the network layer is significantly more expensive than an event-driven callback mechanism. Therefore, if we were to put a work queue data structure into the client, and limit the maximum concurrent requests at that level, we might see significant performance increases even in degenerate cases where our users just spam 5,000 requests in parallel.

This should only take a few hours to prototype, to determine whether the hypothesis holds. If it does, we should formally introduce this into the SDK. We will need to think about what that means for user-specified "request timeout" configurations at that time.

[cprice404]

This should also be explored for python.