feat(TKC-2844): add credentials support

[rangoo94]

Pull request description

• Add credential() function for Control Plane's credentials
• https://github.com/kubeshop/testkube-cloud-api/pull/1633

Checklist (choose whats happened)

• breaking change! (describe)
• tested locally
• tested on cluster
• added new dependencies
• updated the docs
• added a test

Fixes

• https://linear.app/kubeshop/issue/TKC-2844/add-basic-credentials-support

[vsukhin]

please resolve deprecated method issues

[rangoo94]

please resolve deprecated method issues

@vsukhin, I'll try to do it later, although it's not a new code - I only moved it to a different file.

[rangoo94]

@vsukhin, I have checked the client, and unfortunately, if we avoid the deprecated functions, we will lose access to the Connection Error. I don't think that we should do that yet - it happens that we are debugging based on that.

[vsukhin]

ok, but library authors claim it as an especially bad approach)
https://github.com/grpc/grpc-go/blob/master/Documentation/anti-patterns.md#especially-bad-using-deprecated-dialoptions

[rangoo94]

ok, but library authors claim it as an especially bad approach)

@vsukhin, yes, they write that, and I agree with their general statement:

The reason these options can be a problem is that connections with a ClientConn are dynamic -- they may come and go over time. If your client successfully connects, the server could go down 1 second later, and your RPCs will fail. "Knowing you are connected" does not tell you much in this regard.

But the thing is that we do not control infrastructure where Testkube will be installed, so for us it's very helpful to verify the initial gRPC connection immediately. It will change, when we will have a tooling for troubleshooting, but for now - it's the only way we are able to verify if there are no problems with gRPC connection (like incorrectly configured ingress/egress, or connection cut by some proxy).

Even in that docs, they say:

Some users of Dial use it as a way to validate the configuration of their system. If you wish to maintain this behavior but migrate to NewClient, you can call GetState, then Connect if the state is Idle and WaitForStateChange until the channel is connected. However, if this fails, it does not mean that your configuration was bad - it could also mean the service is not reachable by the client due to connectivity reasons.

But the thing is, that GetState + Connect + WaitForStateChange is basically the same as DialContext behavior, but without specific connection error - so it's not helpful for troubleshooting.

Given that, I don't think that we should change it at this point. We can consider it again:

• when we will have nice automated tooling for troubleshooting
• as a separate ticket, as it may have some caveats even besides error (like race conditions, as the connection would no longer be blocking)