Line Filter: Add regex option to line filter

[gtk-grafana]

Part of: #952
Parent branch: #956

Search for IPs:

case insensitive regex

case sensitive regex

[matyax]

One issue with regex is that we're setting it based on the stored preference and not the filter contents.

[matyax]

It's almost there. There is an issue to resolve when you share or reuse a URL, because the regex state doesn't depend on the filter contents. Also it seems that even with regex turned out we're producing and interpreting regexes (the URL I open in incognito with the regex correctly produces log results).

Demo.mov

[matyax]

After seeing #956 and this PR, I think we should change the approach:

• Regex on, show "case sensitive/case insensitive" toggle. Changing it changes the regular expression.
• Regex off, don't show sensitiveness toggle, always produce a Line filter.
• Parse URL: if the URL contains a regex, set regex to true, parse the regular expression, parse case sensitiveness and also set the state.

So we either produce regular expression queries (case sensitive or not), or plain text line filters.

[gtk-grafana]

Well ****

if the filter is case sensitive && no regex, it has |=
If the filter is case insensitive && no regex, it has |~ (?i)
If the filter is case sensitive && regex: it does not have |~ (?i)
if the filter is case insensitive && regex: it has|~ (?i) <-- uh oh, same as case 2

So we need to store the sensitive, regex options in the URL so shared URLs can be parsed appropriately.

I disagree that making the options mutually exclusive is the solution (undesirable UX), but I agree that the options that are set should be pulled from the URL. The values stored in local storage should only set the default.

We'll need to make sure that when we change the options we don't overwrite the users default for other queries (i.e. only when the user clicks on a button). Also when options change we'll need to convert and escape the value appropriately.

Potential solutions:

• Serialize options with the value in the URL
• Store the options in an ad-hoc variable filter

I think the next step is a PoC with the ad-hoc solution.
An ad-hoc variable filter has an index, operator, and value.
Index is unused for line filters.
Operator is |=, |~, !=, !~
Value is whatever the user typed, appropriately escaped based on the operator
Where does case sensitivity go? Drop it into the index? That might not play nice with the default ad-hoc filter renderer.

But yeah I guess that we should find out in the PoC: can we use the existing variables and renderers for line filters with case,regex options (and what provides best support for more options in the future, e.g. ip function, word wrap, other global regex options etc).