potential kds goroutine leak

[Icarus9913]

Kuma Version

master

Describe the bug

When I went through the kds codes, I found that there would be a case to lead goroutine leak.

For example,
on ZoneCP we start startGlobalToZoneSync in a goroutine
https://github.com/kumahq/kuma/blob/2.12.0/pkg/kds/mux/client.go#L115,

later, we'll call OnGlobalToZoneSyncStarted callback function and it's running in a goroutine.
https://github.com/kumahq/kuma/blob/2.12.0/pkg/kds/mux/client.go#L138

Also, the handleProcessingErrors would be stuck waiting for the processingErrorsCh channel
https://github.com/kumahq/kuma/blob/2.12.0/pkg/kds/mux/client.go#L257-L263

And, if you go back to check the OnGlobalToZoneSyncStarted callback function
https://github.com/kumahq/kuma/blob/2.12.0/pkg/kds/zone/components.go#L74-L85

There might be a case that once if we hit the error context.Canceled, we won't send error to the errChan channel. In such a situation, the above handleProcessingErrors function would be stuck indefinitely

To Reproduce

No response

Expected behavior

no goroutine leak

Additional context (optional)

No response

[Icarus9913]

Another one is, we start 6 goroutines and share one errorCh channel
https://github.com/kumahq/kuma/blob/2.12.0/pkg/kds/mux/client.go#L110-L116

But, we would only receive this error channel one time. In this case, the other 5 goroutines may be stuck sending the error to this error channel
https://github.com/kumahq/kuma/blob/2.12.0/pkg/kds/mux/client.go#L118-L125