Prevent context deadlines exceedances

[rfranzke]

How to categorize this PR?

/area scalability
/kind enhancement
/priority normal

What this PR does / why we need it:
@timebertt suggested to use the timeout context introduced with #102 for the reconciliations/health checks themselves, but not for the status updates. This PR is implementing the suggestion.

Along the way, I found that the QPS/burst settings for the client are only applied for the uncached client. However, Gardener disabled the cached client for GRMs deployed as part of the shoot cluster, so the default QPS/burst settings apply which are very low. I've adapted it and do now apply the settings for both cases.

Special notes for your reviewer:
/invite @timebertt @timuthy

Release note:

The client QPS and burst settings do now also apply for the uncached client.

[timuthy]

@timebertt suggested to use the timeout context introduced with #102 for the reconciliations/health checks themselves, but not for the status updates. This PR is implementing the suggestion.

Have we seen timeout problems due to conflicts or what's the motivation? Shouldn't we then rather switch to patching the conditions?

[rfranzke]

Have we seen timeout problems due to conflicts or what's the motivation?

I think the motivation is to always propagate a reconciliation result to the status even if the reconciliation itself timed out (for whatever reason). If the same context is used then the status update call will not succeed if the context timed out.

Shouldn't we then rather switch to patching the conditions?

Probably yes, but I guess this can be done separately in the future / is not really related to this PR.

[timuthy]

/lgtm

[timebertt]

Thank you!
/lgtm