fix: use sendThreadPool in sendEvents

[kevink-sq]

Summary

Issue #108

This PR consists of 2 main changes to address a performance bottleneck in the Amplitude client:
(1) Pass cached thread pool to supplyAsync
(2) Allow users to set sendThreadPool and retryThreadPool

During performance testing it was found Amplitude client would bottleneck on the default ForkJoinPool invoked indirectly via CompletableFuture.supplyAsync(runnable) which is not ideal for I/O:

Many threads were parked due to Amplitude during testing and increasing the fork join pool resolved the issue.

Checklist

• Does your PR title have the correct title format?
• Does your PR have a breaking change?: no

[izaaz]

@kevink-sq - It looks like one of the tests is failing with this change. Since we are using the same thread pool for both sending with retry and sending the actual events, the task to send with retry uses up a few threads on the pool and then chokes the actual sending tasks? This problem goes away when you use two different thread pools for send with retry and actual sending or if you replace the executor service with a fork join pool.

[kevink-sq]

@izaaz - Updated the PR to run supplyAsync in the cached threadpool (which has no bound). You were right about the reused sendThreadPool locking up tasks and I'm glad the tests caught that. Please let me know if you require anything else.

[kevink-sq]

@izaaz bump

[kevink-sq]

@izaaz gentle bump

[github-actions]

🎉 This PR is included in version 1.12.4 🎉

The release is available on:

• GitHub release
• v1.12.4

Your semantic-release bot 📦🚀