Implement saved queries and filters

[Bargs]

Summary

This PR introduces "saved queries". Saved queries are a new saved object type similar to saved searches but more limited in scope. They allow users to store the the query string in the query bar and optionally the set of filters and timefilter in order to reload them anywhere a query is expected: Discover, Visualize, Dashboard, anywhere that uses our full SearchBar component.

TODO

• Add docs about saved queries

---

not implementing, decided to keep saved query UI contained in popover
- [ ] Support partial matches on saved query names in the autocomplete
- [ ] Make a decision on how to handle saved queries where the full search bar is not used
- [ ] Accessibility: ensure all functionality inside the autocomplete’s saved query row is mirrored in “manage” popover
- [ ] Accessibility: try to make the saved query row in autocomplete tabable
- [ ] Implement dirty state indicator and quick save in the right hand side of the query bar input
- [ ] Saved queries not loading in filters agg

• Update and write new tests
  • Finish off unit tests for saved query service
  • General functional tests
  • Security tests (example)
    • Finish adding uiCapabilities conditions to Visualize, Dashboard and Discover
    • Write tests checking for existence of query bar input save UI in discover
    • Write tests checking for existence of query bar input save UI in other apps
    • Write tests checking for existence of saved query management popover save UI in all apps
• Add some sort of indicator of currently loaded saved query
• Make sure all added strings are internationalized
• Add confirmation modal when deleting saved queries
• Try removing saved query controls from autocomplete
  • Make sure places like filters agg editor and tsvb are updated if need be
• Use saved query title as saved object ID? (so titles are unique)
• Update Visualize and Dashboard to use the new saved queries
• Remove number from the manage button
• Inside manage popover, add paginated list of all saved queries in alphabetical order. Load on click. Add delete button per item.
• Make distinction between saved search and saved query more clear
  • Add nouns to save buttons and descriptions where missing
  • Add tooltip to save buttons in the top row of apps
  • Come up with better wording with Gail
• Implement "clear saved query" button in bottom row

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]

💔 Build Failed

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

[elasticmachine]

💚 Build Succeeded

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

[timroes]

Just FYI, in case you weren't aware of it so far (if so ignore me): FunctionComponent has also a version (like SFC beforehand) just called FC for people who don't like typing ;-)

[timroes]

Tested on Chrome Linux, seems to work as expected. I've left a couple of minor code suggestions and nitpicks.

There is only one thing that I am wondering about: We discussed earlier some future enhancement, of being able to use saved queries as part of another query, by using a syntax like: #savedQuery and something:else. We currently allow whitespace characters in the name for the saved query which makes this parsing a bit trickier, or basically we would need another syntax like #{saved query} and something: else, since we otherwise have a hard time figuring out which spaces belong to the name and not. Is this something we should already consider now? I especially came across that, since we currently don't trim trailing/leading spaces, so you can have saved queries named "test", "test ", and "test " all at the same time, though this doesn't really make the scenario above more difficult then allowing spaces at all in the query name.

[elasticmachine]

💚 Build Succeeded

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

[Bargs]

@timroes names with whitespace in them are actually easy to handle in KQL because we require explicit ands and ors. We don't split on whitespace like the query_string query used to. We should trim whitespace at the beginning and end though, that would be annoying to deal with because we currently allow you to use as much whitespace as you want between terms and operators in KQL.

[elasticmachine]

💚 Build Succeeded

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