feat(ui): add flux query builder

[sranka]

This PR adds a new Flux Query Builder that lets users build a flux query using available buckets, available tag names, and tag values.

Its functionality is almost the same as in the v2 UI. It is technically not a backport, the situation in chronograf is a bit different to v2 UI in many aspects (more supported databases, different UI technologies, single and different flux editor, different state management ...)

The key features of the new query builder are (comparing to the existing chronograf flux Schema explorer):

• it always builds a complete flux query/script
• it is always scoped to a selected time range
• offers new tag keys and values based on already selected tag keys and tag values
• scales well even with big tag name/value spaces, the background queries are limited to 200; the user can search for key names/values.

The existing Query Wizard dialog was removed, its functionality was a simple subset of the Flux Query Builder.

• CHANGELOG.md updated with a link to the PR (not the Issue)
• Well-formatted commit messages
• Rebased/mergeable
• Tests pass

[timhallinflux]

we ran into a couple of issues recently re: only fetching the first 200 tags, fields, etc. Essentially, this leads to a bad user experience for a couple of reasons: 1) there is no indication that its a partial result set and 2) there isn't a way to ask for more than 200 results. I would like to avoid repeating this experience.

[timhallinflux]

Script Editor > Query Editor

[sranka]

we ran into a couple of issues recently re: only fetching the first 200 tags, fields, etc. Essentially, this leads to a bad user experience for a couple of reasons: 1) there is no indication that its a partial result set and 2) there isn't a way to ask for more than 200 results. I would like to avoid repeating this experience.

@timhallinflux I see that a v2 UI solution was added 2 weeks ago. The limit is increased to 500 with a feature flag (influxdata/ui#3703). I can extend the limit herein quickly to 500 to follow the approach of v2 UI. I would rather create a new PR on top of the existing one to implement a functionality that would let the user load more data. WDYT?

[timhallinflux]

I believe that is a short term fix. Something else will be done to address this longer term.

But it seems like the idea is to essentially keep these implementations more closely aligned?

As opposed to just making some changes to how the schema is fetched (using the new Flux schema package?) and keeping the original design that Chronograf provided? In some ways the tree view works better than the filter panels...

[sranka]

But it seems like the idea is to essentially keep these implementations more closely aligned?

We should keep them close from the functional perspective, but they already have to diverge in many aspects from the implementation POV.

As opposed to just making some changes to how the schema is fetched (using the new Flux schema package?) and keeping the original design that Chronograf provided? In some ways the tree view works better than the filter panels...

The new Flux's schema package (at the moment) would not bring any improvement regarding the stability and scalability of the implementation. There is no extra optimization, it executes the same queries as the current chronograf implementation does. Chronograf implementation intentionally does not rely upon flux's schema package in order to support older 1.x and 2.x databases.

I also believe that the existing Schema tree is vital and also traditional in many use cases, but it does not scale well with huge data set by design ... unlike the filter panels that cumulatively restrict the data set to choose from. This PR is a solution to #5833 and https://github.com/influxdata/feature-requests/issues/329, these are use-cases that would not be possible with the existing Schema tree view.

There are still some changes that would improve UX of the existing Schema tree, restricting the data set to a user-selected window (not 30days OOTB) will help the most. It is reported in #5849, it will be the next improvement to implement in 1.9.4 . It won't be a big implementation challenge.

[timhallinflux]

some visual clue that the schema tree is controlled by the time range selector...would be helpful. 2.x starts with the last hour ...and if the initial date loaded is beyond that, it is confusing as the user doesn't realize they need to adjust the time range in order to see it.