[Proposal] Migrate `waitForSidecar` to `v1.0/healthz/outbound` to provide parity with dotnet SDK

[olitomlinson]

Describe the proposal

• In WaitForSidecarAsync in the dotnet SDK, it waits for a specific health check against v1.0/healthz/outbound https://github.com/dapr/dotnet-sdk/blob/17f849b17505b9a61be1e7bd3e69586718b9fdd3/src/Dapr.Client/DaprClientGrpc.cs#L1758-L1785

• In waitForSidecar in the Java SDK, it just waits for the dapr http port to become available

  java-sdk/sdk/src/main/java/io/dapr/client/DaprClientHttp.java

  Lines 138 to 146 in cf8040d

  	public Mono<Void> waitForSidecar(int timeoutInMilliseconds) {
  	return Mono.fromRunnable(() -> {
  	try {
  	NetworkUtils.waitForSocket(Properties.SIDECAR_IP.get(), Properties.HTTP_PORT.get(), timeoutInMilliseconds);
  	} catch (InterruptedException e) {
  	throw new RuntimeException(e);
  	}
  	});
  	}

In my opinion, the dotnet SDK provides a more explicit implementation that is better isolated from accidental change.

For example, if the ordering of a dapr runtime init ever changed (accidentally or deliberately), and the dapr http port was open before all components were initialised, then this would cause a break in behaviour.

Therefore, for this reason, I propose that the Java SDK (and other SDKs) should follow the same behaviour as the dotnet SDK and wait for a successful response from v1.0/healthz/outbound rather than just waiting for the dapr http port to be open.

---

This is my understanding of the relationship between Dapr and the App during init

[cicoyle]

/assign

[cicoyle]

once the docs PR I have open gets merged, then this issue can be closed.