Putting this in 5.8, but this should not block the release (it's a bonus).

1. The underlying REST client is reactive. We may want to take advantage of that when executing works asynchronously. For instance, we could completely remove our thread pool, simply send requests (asynchronously) when we are instructed to execute works and rely on callbacks for error handling.
2. We could experiment with Bulking together synchronous works from different threads... It would basically mean, in the executeSyncUnsafe case, that we'd send all works to a consumer

I'm a bit less sure about 2, mainly because it may make things much harder to debug, but we can try... once we have proper performance tests and a baseline.