Consumer creates/updates and stream updates would spin up multiple (redundant) goroutines, potentially allowing the system to become overloaded.

if c.kind != ROUTER && c.kind != GATEWAY we're already running a goroutine because it will be done by the JS API pool, that uses a JETSTREAM client, so it would then open yet another goroutine. Due to this other goroutine we also lose visibility on requests that take a long time, because the Internal subscription on %q took too long: %v only gets logged if taking a long time AND we've not spun up a different goroutine to do the actual work that could take time, making this logging ineffective. These additional goroutines could also result in being able to quickly overwhelm the API. Client connections would block and handle these inline (sometimes), but routers/gateways would spin up additional goroutines and could quickly zip through all requests and spin up many many goroutines all waiting for the same locks.

This PR makes JS API handling consistent by always having API requests go through the pool. This ensures we're never blocking the requests for any connection, we're consistent in the amount of goroutines that can run (will always equal the pool size, except when listing streams/consumers since they run in a separate goroutine), we're consistent in dropping API requests when required, and we can effectively log when processing takes too long.

Signed-off-by: Maurice van Veen github@mauricevanveen.com