Consider reducing webhook timeout

[anyasabo]

Follow up from:
#1634

With the 30s timeout in the webhook config and the 30s timeout in clients, it seems like we may want to reduce the validating webhook configuration timeoutSeconds to less than 30s. Kubectl clients and the operator can fail to update ES resources. I wonder if we should reduce it to 10s (or maybe even less?)? The validations run quite quickly so we should be able to process them all in much less than 30s, and if the network is misconfigured such that the webhook times out, at least the clients do not time out and can proceed.

I worry a little bit that this is a bandaid over a problem, but it seems like changing this would allows the webhook to "fail open" rather than closed, which seems like a benefit.

I also wonder if we want to make a docs section about "working with my elastic resources is slow" and point them to webhook troubleshooting.

Also reference:
https://discuss.elastic.co/t/elastic-operator-requests-regularly-time-out/219096
#2545

[anyasabo]

Ah I remembered why we did not do this earlier, the timeout field was only introduced in 1.14:
kubernetes/kubernetes#74562

You can apply it in earlier versions, but client-side validation in kubectl will error out. You need to pass --validate=false for kubectl apply to work.

Should we keep this open pending us dropping support for <1.14?