fix(influxql): don't expand large regex char sets

[dgnorton]

fixes influxdata/influxdb#13929

InfluxQL optimizes some queries by expanding regular expressions in the
WHERE clause to literal expressions. This causes a problem when the
expression expands to a large number of literals. This change caps it at
100 literals. If the expression would expand to more, it is not
optimized at all (i.e., no partial optimization).

[jsternberg]

I think the max should be lower, but the code is solid so whichever number it is this can be approved.

[jsternberg]

I think 100 is a better value. 1000 is likely too high.

[dgnorton]

👍 fixed

[e-dard]

This is right approach, but we need to change a couple of things here:

1. we can't introduce a change like this that could break existing users' queries without a form of control. We need to propogate maxLiterals all the way back to a configuration file option in InfluxDB. The default of 100 seems reasonable.
2. when I tested this I just got a normal info message saying the query executed, but no error or indication the query failed. We need to be able to inform the user that their query failed, if indeed it did.

Further, when the PR to InfluxDB is made, we need to add then config option to the demo config with some description of what it does. We also need to let the docs team know about this change.

[dgnorton]

@e-dard

1. This change shouldn't break any existing queries because it is just limiting a query optimization. E.g., take a query with regex that would expanded to 100,000 literal comparisons. Prior to this change, the expansion would have happened and the rewritten query might have executed on a machine with sufficient resources. After this change, the query will not be rewritten and it will execute correctly on any machine.
2. No error occurs. It's just a matter of whether a query was optimized or not.

[e-dard]

@dgnorton ah OK I misunderstood the function's purpose. This makes a lot of sense! We should still document in the InfluxDB release notes (top of the changelog) that the optimisation has now been limited to XYZ expressions.