Don't cancel timeout context after failure and first loop

[ibuildthecloud]

By canceling the timeoutCtx here it has the side effect that any
cache later in the toWait list will be canceled if it hasn't finished
yet. The side effect of this is that we only really wait for the
first cache and then if any other cache isn't don't we cancel them.

This is the source of errors like

failed to sync schemas: failed to sync cache for /v1, Kind=Secret

You may see these errors in the Rancher cluster agent when Steve is
starting, but you will definitely see these errors when running wtfk8s.

Signed-off-by: Darren Shepherd darren@acorn.io

[ibuildthecloud]

There's no need to cancel this context as it's canceled in the defer at the top.

[ibuildthecloud]

@kinarashah Could you please review, I can't assign reviewers.

[ibuildthecloud]

Can someone please, please, please merge this?

[KevinJoiner]

Which problem are we trying to solve here

1. When we have multiple watchers we are not waiting for all caches to sync.
2. When we have multiple watchers we incorrectly error every-time.

If we are only trying to solve problem 2 would this not cause us to wait for a sync that we do not care about?
I ask because I am not sure what the original intent was for canceling after a successful sync.

[ibuildthecloud]

The issue is closer to When we have multiple watchers we incorrectly error every-time.. When we have multiple watchers if one fails, we fail them all current, which is not good. I'm the original author of this code and the original assumption was that basically caches rarely fail to sync and any such error would be transient. That assumption is not true as one persist and easy way to cause a cache to fail syncing is if a custom apiserver is down. So when that happens a lot fails.