[VC-36032] Configure controller-runtime to log with klog

[wallrj]

I assume that the controller-runtime logs were being discarded.
With this change I hope to find some controller-runtime logs among the e2e test logs.

Testing

$ make test-e2e-gke
...
{
  "ts": 1732123466929.3813,
  "caller": "metrics/metrics.go:97",
  "msg": "cache not synced yet, skipping metrics venaficonnection_*",
  "source": "controller-runtime",
  "v": 0
}
...
{"ts":1732123472568.4834,"caller":"agent/run.go:409","msg":"Data sent successfully","v":0,"logger":"Run.gatherAndOutputData.postData"}

That single message seems to come from venafi-connection-lib, so perhaps it's misleading to label these logs with source: "controller-runtime":

• https://github.com/jetstack/venafi-connection-lib/pull/146
• https://github.com/jetstack/venafi-connection-lib/blob/13c2342fe0140ff084d2aabfd29ae3d10721691b/internal/metrics/metrics.go#L92-L102

@maelvls Does that log message indicate a bug in the way we're instantiating the venafi-connection-lib client?

[wallrj]

This was from #552:

• Add support for the VenafiConnection CRD so that users can start using the Workload Identity Federation authentication ("secretless") #552

[wallrj]

I changed this so that could see trace level logs in the e2e test.
As it happens, the single controller-runtime log message from venafi-connection-lib is at level 0, so this change is not strictly necessary.

[maelvls]

cache not synced yet, skipping metrics venaficonnection_*

I remember adding this log line in venafi-connection-lib's metrics.go (internal link). I remember writing this:

// We found a niche problem where `/metrics` would hang forever in case of a
// misconfigured RBAC. This was due to `cache.List` hanging until the cache
// is synced. To prevent that, we skip reporting this subset of the metrics.
if !hasSynced(cc.cache) {
	cc.log.Info("cache not synced yet, skipping metrics venaficonnection_*")
	return
}

I don't know why WaitForCache is taking so long to return. The Helm chart's RBAC is correct, so it shouldn't be this... This needs debugging, but we can do that in the next PR.