Increase leader election settings for shoot's GRM

[rfranzke]

How to categorize this PR?

/area cost networking robustness
/kind enhancement
/priority normal

What this PR does / why we need it:
We run one GRM per shoot control plane, and the GRM is doing its leader election via configmaps in the seed - by default every 2s. This can lead to a lot of PUT /v1/configmaps requests on the API server, and given that a seed is very busy anyways, we should not unnecessarily stress the API server with this leader election. The GRM's sync period is 1m anyways, so it doesn't matter too much if the leadership determination may take up to one minute.

Which issue(s) this PR fixes:
Part of #1953

Special notes for your reviewer:
✅ Depends on gardener-attic/gardener-resource-manager#72 and a new release.
/invite @timebertt @vlerenc

Release note:

It is now possible to specify the leader election settings via the following command line parameters: `--leader-election-lease-duration` (default: `15s`), `--leader-election-renew-deadline` (default: `10s`), `--leader-election-retry-period` (default: `2s`).

The leader election performed by the `gardener-resource-manager` deployments in shoot namespaces in the seed is now happening less frequently to prevent overloading the seed's API server unnecessarily.

[rfranzke]

/invite @zanetworker @wyb1 @istvanballok

[vpnachev]

/lgtm

[ialidzhikov]

/lgtm

[rfranzke]

/ready

[zanetworker]

/lgtm

[timebertt]

Thanks!
/lgtm

WDYT about adding a release note, that the grm LE config is changed now and CM updates should be reduced now?

[rfranzke]

@timebertt I didn't add one on purpose as I wasn't sure how this information is helpful to an operator/admin, or? It's rather an internal detail, isn't it?

[timebertt]

As you like :)
Still, I think cutting down some of the large amount of requests, that we have seen and that have caused some serious issues, is not an internal detail 😉

[rfranzke]

OK, I've added a small note now.