Switch Discover and Settings tests to use esClient to wipe .kibana

[LeeDr]

A couple of API tests are still using scenarioManager.reload('emptyKibana') but this is the last of the functional tests using it.

[LeeDr]

The functional tests passed but then the build failed after that (I'll start it again);
http://build-eu-00.elastic.co/job/kibana_core_pr/3951/console

Running "esvm:ui" (esvm) task
starting up "ui" cluster
INFO -  - cluster - Downloading & installing from "master" branch.

Build timed out (after 30 minutes). Marking the build as aborted.
Build was aborted

[LeeDr]

jenkins, test it

[jbudz]

jenkins, test it

[jbudz]

this seems to be a common enough occurrence, do you think it's worth wrapping this with a method that overwrites the kibana index with a dump that sets default configs and saved objects?

[LeeDr]

There's actually a couple of different cases now.

1. For Settings tests, we delete the .kibana index
   and then call getConfigId() just as a means to wait for it to be re-created.
2. For Discover and Visualize tests, we delete the .kibana index and then call esClient.updateConfigDoc({'dateFormat:tz':'UTC', 'defaultIndex':'logstash-*'}) (which calls getConfigId())
   and load the logstash index pattern with elasticDump.
3. For Dashboard tests, we delete the .kibana index and then call esClient.updateConfigDoc({'dateFormat:tz':'UTC', 'defaultIndex':'logstash-*'})
   and load the logstash index pattern and saved visualizations with elasticDump.

Maybe a deleteAndUpdate(index, configDocMap) method which deletes the index, and gets the configId, and optionally does the configDocMap if it's passed in.

[LeeDr]

@jbudz take a look at the method I created to wrap the common delete and update scenarios.

[jbudz]

LGTM