Replacing OkHttpClient with Java 11 HttpClient

[artur-ciocanu]

Description

A few months ago we have upgraded Dapr Java SDK to use Java 11. Java 11 has native support for HTTP client. The proposal is to use the Java 11 HttpClient instead of OkHttpClient. While OkHttpClient is a nice library it adds yet another dependency that we have to manage and upgrade. Also the fact that OkHttpClient uses Kotlin adds another layer of complications since the Kotlin version in OkHttpClient might conflict with our customers Kotlin stdlib.

Issue reference

We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.

Please reference the issue this PR will close: #1217

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Extended the documentation

[artur-ciocanu]

@artursouza @cicoyle and @salaboy please take a look and let me know your thoughts. We are still using OkHttpClient in ITs, but I will take care of those in a separate PR, so this is more focused.

[artur-ciocanu]

@artursouza I might need your help, as far as I can see the only failing test WaitForSidecarIT.waitSlow() this test uses ToxiProxy I am not sure why it fails. Is OkHttpClient doing something smart behind the scenes compare to Java 11 HttpClient?

[artur-ciocanu]

@artursouza and @cicoyle with @ThomasVitale's help I have managed to fix the ITs. Everything is 🟢. Could you please review.

[salaboy]

@artur-ciocanu this looks good to me.. just the license header is missing on that one file

[cicoyle]

lgtm. Thanks for adding the READ_TIMEOUT for consistency

[artursouza]

Thanks a lot @artur-ciocanu. I have two questions above. The point about the test is that in Project Reactor, all actions need to be lazily resolved - we validate it by making sure nothing is invoked until .block() is called. This is basic expectations.

Now, there is a major piece of work that we can consider (another PR), which is to move the SDK away from Project Reactor and use CompletableFuture only (https://www.baeldung.com/java-asynchronous-programming#completableFuture). I am not in favor of using another 3rd party async API anymore :)

[artur-ciocanu]

@artursouza I have added back the test related to multiple Monos, could you please take another look. Thank you!