Wait for webhook key to be present in filesystem

[anyasabo]

@thbkrkr brought up out of band that he intermittently received this error starting the operator

{"level":"error","@timestamp":"2019-12-19T15:35:28.548Z","logger":"manager","message":"unable to run the manager","ver":"1.0.0-rc3-ae5f8e81","error":"open /tmp/k8s-webhook-server/serving-certs/tls.crt: no such file or directory","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error
	/go/pkg/mod/github.com/go-logr/zapr@v0.1.0/zapr.go:128
github.com/elastic/cloud-on-k8s/cmd/manager.execute
	/go/src/github.com/elastic/cloud-on-k8s/cmd/manager/main.go:331
github.com/elastic/cloud-on-k8s/cmd/manager.glob..func1
	/go/src/github.com/elastic/cloud-on-k8s/cmd/manager/main.go:81
github.com/spf13/cobra.(*Command).execute
	/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:830
github.com/spf13/cobra.(*Command).ExecuteC
	/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:914
github.com/spf13/cobra.(*Command).Execute
	/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:864
main.main
	/go/src/github.com/elastic/cloud-on-k8s/cmd/main.go:27
runtime.main
	/usr/local/go/src/runtime/proc.go:203"}

I suspect that this is because we return setupWebhook() as soon as we update the secret with the generated key, but it may take more time for the kubelet to update the container's file system with the new contents of the secret. I'm not sure there's a simple way to write a test for this, but it worked in my testing. This is more of a proof of concept of checking for it, definitely open to alternate approaches if this is something we want to do.

[thbkrkr]

LGTM!

We have been dragging this issue since v0.8. Nice to see it disappear now.