New gRPC DaprClient fails for Secret API requests if mTLS is enabled

Expected Behavior

DaprClient should work with mTLS enabled.

Actual Behavior

clients created through the builder:

var client = new DaprClientBuilder().Build();

Fail to get secrets through calling client.GetSecretAsync when Dapr mTLS is enabled.

Steps to Reproduce the Problem

Deploy the following yaml to K8s:

---
# Create a Kubernetes Secret
apiVersion: v1
kind: Secret
metadata:
  name: super-secret
  namespace: default
type: Opaque
data:
  super-secret: eW91ciBzdXBlciBzZWNyZXQK

---
# If RBAC is enabled in K8s, give the default SA access to secrets in the default namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dapr-secret-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: secret-reader
subjects:
  - kind: ServiceAccount
    name: default
    namespace: default

Create and deploy an ASP.NET Core application which implements the following call:

var secrets = await client.GetSecretAsync("kubernetes", "super-secret", new Dictionary<string, string>() { { "namespace", "default" } });

The call will fail with mTLS enabled.

[amanbha]

@cmendible I have published new package version 0.5.0-preview02 witht he changes.

[amanbha]

@cmendible Please see this PR https://github.com/dapr/dotnet-sdk/pull/263 It will be cherry-picked into 0.5.0 branch to release a new nuget package to see if it works for you. There is an internal method on DaprClientBuilder, its UseGrpcChannelOptions(). I am thinking of making it public to allow for more configurable brhavior form users in future, any feedback around it? The change will be reverted from master branch for 0.6.0 when the issue is fixed in Dapr runtime.