parser: return errors if there are syntax bugs in metric names wrapped by a function

[bom-d-van]

What issue is this change attempting to solve?

In the current implementation, carbonapi returns 400 errors for queries like ns1.ns2.foo-[a b] or ns1.ns2.foo-{a, b}.
However, if these types of queries happened to be wrapped around within a function, like sumSeries, that accepts
metrics list, no errors are returned. As they are treated as individual metrics and sent to storage, storage would
returns 400 as well.

How does this change solve the problem? Why is this the best approach?

This commit fixes the issue, by generating a parser error if spaces and comma appears inappropriately within []/{}.
At the same time, nested range list (like [[]]) and unclosed ([/{) or unopened (]/}) ranges or value list are also
reported as errors, instead of treating them as proper query and forwarding them to storages.

As consequence of this change, some of the requests that are originally returning 200 would be returned with 400
status codes.

How can we be sure this works as expected?

Original tests still pass and new test cases are added.

[grzkv]

@bom-d-van Can we please keep different changes in separate PRs? Linter change makes sense to do separately, and then back-merge from master.

[grzkv]

@bom-d-van I believe, we need to manually test a change in syntax like this one before merging to master, because it is potentially breaking. We try to keep the promise of master always being in a working condition.

[bom-d-van]

Can we please keep different changes in separate PRs? Linter change makes sense to do separately, and then back-merge from master.

I would appreciate we just do it in one MR. The commit is already different.

[bom-d-van]

I believe, we need to manually test a change in syntax like this one before merging to master, because it is potentially breaking. We try to keep the promise of master always being in a working condition.

I already tested it on a staging server. What else do you propose?
There might be new cases that we need to cover, we can include them in unit tests.

[grzkv]

Can we please keep different changes in separate PRs? Linter change makes sense to do separately, and then back-merge from master.

I would appreciate we just do it in one MR. The commit is already different.

Sure. I'd appreciate if we did it in the future though.

[grzkv]

I already tested it on a staging server. What else do you propose?

Great. This is exactly what I had in mind.