First of all thank you very much for this wonderful library!

I have a workaround for the following issues and it might be rather edge cases but it would be nice if you could have a look at these.

My first issue is, when requests are sent fast after each other (for the same playlist in this case) I get the following exception:

java.lang.IllegalStateException: Connection 192.168.1.48:58156<->35.186.224.25:443 is still allocated
	at org.apache.hc.core5.util.Asserts.check(Asserts.java:50) ~[httpcore5-5.2.4.jar:5.2.4]
	at org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager.getConnection(BasicHttpClientConnectionManager.java:306) ~[httpclient5-5.2.3.jar:5.2.3]
	at org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager$1.get(BasicHttpClientConnectionManager.java:235) ~[httpclient5-5.2.3.jar:5.2.3]
	at org.apache.hc.client5.http.impl.classic.InternalExecRuntime.acquireEndpoint(InternalExecRuntime.java:109) ~[httpclient5-5.2.3.jar:5.2.3]
	at org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:125) ~[httpclient5-5.2.3.jar:5.2.3]
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51) ~[httpclient5-5.2.3.jar:5.2.3]
	at org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192) ~[httpclient5-5.2.3.jar:5.2.3]
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51) ~[httpclient5-5.2.3.jar:5.2.3]
	at org.apache.hc.client5.http.impl.cache.CachingExec.revalidateCacheEntry(CachingExec.java:313) ~[httpclient5-cache-5.2.3.jar:5.2.3]
	at org.apache.hc.client5.http.impl.cache.CachingExec.handleCacheHit(CachingExec.java:293) ~[httpclient5-cache-5.2.3.jar:5.2.3]
	at org.apache.hc.client5.http.impl.cache.CachingExec.execute(CachingExec.java:200) ~[httpclient5-cache-5.2.3.jar:5.2.3]
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51) ~[httpclient5-5.2.3.jar:5.2.3]
	at org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:96) ~[httpclient5-5.2.3.jar:5.2.3]
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51) ~[httpclient5-5.2.3.jar:5.2.3]
	at org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:115) ~[httpclient5-5.2.3.jar:5.2.3]
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51) ~[httpclient5-5.2.3.jar:5.2.3]
	at org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170) ~[httpclient5-5.2.3.jar:5.2.3]
	at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:106) ~[httpclient5-5.2.3.jar:5.2.3]
	at se.michaelthelin.spotify.SpotifyHttpManager.execute(SpotifyHttpManager.java:253) ~[spotify-web-api-java-8.3.5.jar:na]
	at se.michaelthelin.spotify.SpotifyHttpManager.get(SpotifyHttpManager.java:174) ~[spotify-web-api-java-8.3.5.jar:na]
	at se.michaelthelin.spotify.requests.AbstractRequest.getJson(AbstractRequest.java:110) ~[spotify-web-api-java-8.3.5.jar:na]
	at se.michaelthelin.spotify.requests.data.playlists.GetPlaylistRequest.execute(GetPlaylistRequest.java:38) ~[spotify-web-api-java-8.3.5.jar:na]
	at se.michaelthelin.spotify.requests.data.playlists.GetPlaylistRequest.execute(GetPlaylistRequest.java:15) ~[spotify-web-api-java-8.3.5.jar:na]
	at se.michaelthelin.spotify.SpotifyApiThreading.lambda$executeAsync$0(SpotifyApiThreading.java:17) ~[spotify-web-api-java-8.3.5.jar:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[na:na]
	at java.base/java.lang.Thread.run(Thread.java:1589) ~[na:na]

The problem is, that the requests cannot be processed in parallel or fast after each other due to connection in httpClient is not yet closed. My workaround for now is to synchronize the requests but it would be nice if this could be done in parallel by default.

Another problem is that GET-requests do caching. In my case I do not want caching for GET. I could prevent this issue configuring a custom SpotifyHttpManager without caching (excluding the httpClientCaching etc.). But would be nice if this could be configured by builder-property.

Thank you again for this great library!