Rate-limit new client connection setup to avoid overwhelming bcrypt

A flood of reconnects can cause a ton of pain at the bcrypt phase of validating incoming connections. While this shouldn't happen during normal operations, we need a rate limit server side - if there's a bad client out there (version and/or configuration) that misbehaves, a way to cap the pain on a server is quite useful. Right now the only option is to cap the total connections which has other issues that aren't an ideal tradeoff (inability to connect, etc).

Moving authentication requests to a small, separate pool will prevent starvation handling all other requests. If the authExecutor pool backs up it may cause authentication timeouts, but the clients should back off and retry while the rest of the system continues to make progress.