Add advanced setting to turn off search on Discover's initial page load

[Bargs]

Summary

Related to #7238

Discover currently executes a search as soon as it loads. For some users this is useful. But for others it may return worthless results at the expense of extra load on their ES cluster and increased page load times, making it harder to get to the data they actually want. This PR adds an advanced setting allowing users to turn off the "search on page load" functionality in Discover.

One thing to note is that I chose to continue loading results immediately when loading a saved search (for example, from a bookmark). If you're loading a specific saved search, I think that's an indication that you're interested in seeing its results immediately.

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

- [ ] This was checked for cross-browser compatibility, including a check against IE11

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
  - [ ] This was checked for keyboard-only and screenreader accessibility

For maintainers

- [ ] This was checked for breaking API changes and was labeled appropriately

• This includes a feature addition or change that requires a release note and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-app

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[kertal]

jenkins test this

[kertal]

Code LGTM, tested locally with Chrome, I found one thing to discuss:
When you set a refresh interval, reload discover, initially the unintializedText is displayed until the first interval period is over. I think it would be better to also start the reloading after the first click on refresh

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[TinaHeiligers]

Code LGTM.
I tested the implementation and setting the searchOnPageLoad to false prevents the initial query being sent. The setting also prevents a query being sent on page load if a filter or a query or a date filter has already been applied when navigating away from Discover to another application (Visualize for example) and then navigating back to Discover if no action was taken in the other app.
The steps I took are:

1. Add a filter and issue the request in Discover. We get the results from the search:
   
2. Navigate away from Discover to another app but don't load anything:
   
3. Go back to Discover and the filter/query/date filters are still present but the search request was not issued.
   
   The implementation satisfies the intent of preventing requests on every initial load if the setting is applied and a saved search is not being loaded.

[Bargs]

@kertal I agree with you, the interaction with the auto refresh was a bit weird. I've made two changes:

• A search will now execute as soon as you turn on auto refresh
• A search will execute on page load if auto refresh is enabled, regardless of the new setting's value

@TinaHeiligers The scenario you outlined is one I thought about a bit. If a user is bouncing between apps and they've already applied a query and/or filters in Discover, I'm not sure if they would want to automatically load results every time they bounce to Discover or not. On the one hand, since they entered the query then maybe they want to see those results. On the other hand the old query may be stale and they may be coming back to Discover to execute a new query. Since the primary use of this setting is to reduce load I erred on the side of not automatically loading results in this situation. I figure if someone wants to reference back to one specific query frequently, they can keep it open in a separate tab.

[Bargs]

@AlonaNadler would you like to take a look at this before it is merged?

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[AlonaNadler]

@Bargs haven't checked it out yet just by the screen I have a few suggestions:

• How can we make this to not feel like an empty screen? Maybe @elastic/kibana-design will have a few ideas. We can do something fun here instead of leaving it empty.
• Can we add a few examples for search queries? and work on the wording, maybe @gchaps will have ideas

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[kertal]

Code LGTM, now the refresh interval behaviour is fine, tested with Chrome

[cchaos]

Hey @Bargs I'm gonna push you a PR soon that will fill in that empty state. cc @AlonaNadler

[cchaos]

PR4U: Bargs#8

[Bargs]

Thanks for the PR @cchaos. The only thing I noticed is that the discover results also have a border around them now. Is that intentional?

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[cchaos]

Yes the main results now live in a panel, similar to how we handle other pages within Kibana.

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request