Increase startupProbe rate for plugin pods

[jgehrcke]

In many cases, both the GPU as well as the CD plugin pods are ready to serve requests a couple hundred milliseconds after startup.

The default for initialDelaySeconds (for a startup probe) is zero. That is, the first startup probe happens pretty much immediately, and is likely to fail.

With periodSeconds: 10, we then detect readiness only ~10 seconds after pod startup.

The probe itself is cheap; we can safely increase the probing rate to allow for more snappy readiness detection.

The overall timeout duration has to remain ~long, for the reasons laid out in #774.

--

Downsides?

• Each probe as of now triggers a noop NodePrepareResources request which triggers log messages (at least when on chattiness level 4 and higher). That is, during an actual slow startup there would be more of those messages logged per time. That's a tolerable downside which, if we perceive it as a problem, can be addressed in its own ways without reducing the frequency.
• Does anything else come to mind?

[jgehrcke]

Because we often re-install the Helm chart (and then wait for kubelet plugin readiness), this change has a significant impact on the overall duration of the test suite. Some examples follow:

Overall CI check duration bats-k8s134:

• before: ~9 min
• after: ~6 min

GPU plugin upgrade test:

• before: ~ 45 s
• after: ~30 s

Helm install + wait (explaining the above's speedups):

• before: ~15 s
• after: ~6 s