Re-set default index pattern in navigateToApp

[LeeDr]

Fixes #7496. Several Jenkins selenium test runs have failed again recently when there is a logstash-* index pattern but it is not set as the default even though the test successfully called the method to set it;

esClient.deleteAndUpdateConfigDoc({'dateFormat:tz':'UTC', 'defaultIndex':'logstash-*'})

This could be caused by #7055 where Kibana writes a change to the config doc after the automation set the defaultIndex, thus clobbering it.

This PR works around that by checking if we're navigating to discover, visualize, or dashboard, and don't have a default index pattern set. In that case it logs a WARNING and sets it to logstash-*.

What if we write a test that needs a different default index pattern than logstash-*? We'll have to fix this better.

The easiest way to test this is to change this line in the very first test;
https://github.com/elastic/kibana/blob/master/test/functional/apps/discover/_discover.js#L19

from;

return esClient.deleteAndUpdateConfigDoc({'dateFormat:tz':'UTC', 'defaultIndex':'logstash-*'})

to;

return esClient.deleteAndUpdateConfigDoc({'dateFormat:tz':'UTC'})

This would cause the code below to log the warning and set the default index pattern (and then continue to pass tests).

        return esClient.getDefaultIndex()
        .then(function (defaultIndex) {
          if (appName === 'discover' || appName === 'visualize' || appName === 'dashboard') {
            if (!defaultIndex) {
              // https://github.com/elastic/kibana/issues/7496
              // Even though most tests are using esClient to set the default index, sometimes Kibana clobbers
              // that change.  If we got here, fix it.
              self.debug(' >>>>>>>> WARNING Navigating to [' + appName + '] with defaultIndex=' + defaultIndex);
              self.debug(' >>>>>>>> Setting defaultIndex to "logstash-*""');
              esClient.updateConfigDoc({'dateFormat:tz':'UTC', 'defaultIndex':'logstash-*'});
            }
          }

[epixa]

Does updateConfigDoc return a promise? If so, I think we should return that promise and then do the self.remote.get() call in a followup .then() block.

[LeeDr]

Yes, I think you're right about chaining the returned promise. I'll make that change.

[epixa]

I pushed this up in another PR to make it run the selenium tests, and it failed: https://kibana-ci.elastic.co/job/elastic+kibana+pull-request+multijob-intake/711/consoleFull

[LeeDr]

The failure in https://kibana-ci.elastic.co/job/elastic+kibana+pull-request+multijob-intake/711/consoleFull is caused by the side nav expand/collapse change which is on another issue.

[epixa]

Can you rebase this since we merged that other PR? I'd love to test it together.

[LeeDr]

jenkins, test this