Increase HTTP client timeout in kubernetes state_deployment tests

[jsoriano]

Test data for state_deployment metricset is quite big, and the metricset
may need more than the 10 seconds default timeout of HTTP clients,
provoking sporadic failures in CI.
Increase this timeout for this case.

This should fix flaky tests like:

10:55:29 --- FAIL: TestData (12.25s)
10:55:29     --- FAIL: TestData/ksm-v1.8.0.plain (11.22s)
10:55:29         testdata.go:272: Event was not expected: {"error":{"message":"decoding of metric family failed: net/http: request canceled (Client.Timeout exceeded while reading body)"},"event":{"dataset":"kubernetes.state_deployment","duration":115000,"module":"kubernetes"},"metricset":{"name":"state_deployment","period":10000},"service":{"address":"127.0.0.1:55555","type":"kubernetes"}}
10:55:29         testdata.go:277: Some events were missing:
...
10:55:29         testdata.go:281: 
10:55:29 FAIL
10:55:29 coverage: 74.1% of statements
10:55:29 FAIL	github.com/elastic/beats/v7/metricbeat/module/kubernetes/state_deployment	12.588s

[elasticmachine]

Pinging @elastic/integrations-platforms (Team:Platforms)

[blakerouse]

Why is 10 secs not enough time based on the size of the test data? Seems that 10 sec is a large amount of time for an HTTP request.

[jsoriano]

Why is 10 secs not enough time based on the size of the test data? Seems that 10 sec is a large amount of time for an HTTP request.

Yeah, it should be definitely enough, we could investigate it more later. I would only like to address flakiness of this test by now.

It could be about memory. Big Prometheus responses take a lot of memory in Metricbeat, recently I did some profiling with a 27MB response and it required more than 600MB in Metricbeat. The one in this test case is 12MB big, maybe in an overloaded Jenkins worker this is enough to make things slow.

[blakerouse]

+1 to fix the test for now, but yeah we should look into why it needs that much time.