Even more robust API key auth 429 test

[ywangd]

After discussion with @tvernum, the new SocketTimeoutException is likely due to the authenticate request being put onto the queue instead of the expected rejection. Since the thread pool is intentionally blocked, the authenticate request fails to come back in time.

Here are what likely happend in time order:

1. The previous test is completed, but somehow its associated authentication task has not yet been cleared out of the threadpool. This is evident as shown in the previous EsRejectedExecutionException failure (Make test more robust for API key auth 429 #59077).
2. The current test begins, blocking tasks are submitted to the thread pool.
3. More no-op tasks are submitted in order to fill up the queue. However not all of them can be submitted because of the lingering task from step 1. So instead of 10 tasks, only 9 of them are successfully submitted. We catch the rejection execption and move on.
4. JVM now decides to clear out the lingering task from step 1 from the thread pool. This means the queue now has one empty spot.
5. The authentication request is sent by the client. Since there is one empty spot in the queue, the request is queued instead of being rejected and finally fails because of timeout.

So the fix is to ensure that authentication request in step 5 does not get put onto the queue. This can be ahieved by ensuring all blocking tasks from step 2 are alreadying running before move onto step 3. Once active threads are indeed blocked, we can then be sure that no tasks would be popped out of the queue unexpectedly, which in turn guarantees the rejection of the subsequent authentication request.

Resolves: #59149

[ywangd]

@elasticmachine run elasticsearch-ci/2

[ywangd]

@elasticmachine run elasticsearch-ci/2

[ywangd]

@elasticmachine run elasticsearch-ci/2

[elasticmachine]

Pinging @elastic/es-security (:Security/Authentication)

[ywangd]

@tvernum The tests have been successfully for 5 consecutive runs. It should be good for review. Thanks!

[tvernum]

LGTM