[pkg/telemetryquerylanguage] Support Inequalities in TQL

[kentquirk]

Adds inequality support to TQL.

Previously, TQL supported only == and !=, and only between identical types. With this PR, TQL now also supports <, <=, >=, >, and can compare across different numeric types (two objects of the same type are compared as that type, but objects of differing types are promoted to the most general type -- int/float is compared as float, while int32/int64 is compared as int64.

Link to tracking Issue:
Closes #12491.

Testing:

The testing is fairly extensive:

• The parser has a long set of go/no-go parser tests, just to make sure that the parser can handle various expressions. It is easy to add more tests.
• The compare function has a large set of tests with all of the types represented on both sides of comparisons. It does not exhaustively check every possible combination, because the expected values are constructed by hand, but it comes fairly close.
• Because there were some concerns expressed about performance, I've added some benchmarks for the compare functions. On a 2019 intel macbook, an equivalent to the original comparison function (comparing any values for equality) took about 7 ns/op. The replacement takes between 2 and 12 ns/op, depending on the underlying type (nils are fast, strings are slow, numeric values in the middle). There are no allocations.
• There are more parser tests exercising a wide range of comparison cases.

Documentation:

• Update TQL documentation to explain comparison rules
• Update changelog

Benchmark results (the last line is equivalent to the original function):

goos: darwin
goarch: amd64
pkg: github.com/open-telemetry/opentelemetry-collector-contrib/pkg/telemetryquerylanguage/tql
cpu: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
BenchmarkCompareEQInt-16         	170905822	         7.802 ns/op	       0 B/op	       0 allocs/op
BenchmarkCompareEQFloat-16       	149245143	         7.850 ns/op	       0 B/op	       0 allocs/op
BenchmarkCompareEQString-16      	120490750	         9.471 ns/op	       0 B/op	       0 allocs/op
BenchmarkCompareEQPString-16     	100000000	        10.06 ns/op	       0 B/op	       0 allocs/op
BenchmarkCompareEQBytes-16       	100000000	        10.57 ns/op	       0 B/op	       0 allocs/op
BenchmarkCompareEQNil-16         	442970434	         2.697 ns/op	       0 B/op	       0 allocs/op
BenchmarkCompareNEInt-16         	170016027	         6.994 ns/op	       0 B/op	       0 allocs/op
BenchmarkCompareNEFloat-16       	166002114	         7.190 ns/op	       0 B/op	       0 allocs/op
BenchmarkCompareNEPFloat-16      	167566688	         7.136 ns/op	       0 B/op	       0 allocs/op
BenchmarkCompareNEString-16      	123459964	        10.00 ns/op	       0 B/op	       0 allocs/op
BenchmarkCompareNENil-16         	339125064	         3.066 ns/op	       0 B/op	       0 allocs/op
BenchmarkCompareLTInt-16         	150001532	         7.734 ns/op	       0 B/op	       0 allocs/op
BenchmarkCompareLTPInt-16        	149175864	         8.466 ns/op	       0 B/op	       0 allocs/op
BenchmarkCompareLTFloat-16       	164382165	         7.826 ns/op	       0 B/op	       0 allocs/op
BenchmarkCompareLTString-16      	100000000	        10.47 ns/op	       0 B/op	       0 allocs/op
BenchmarkCompareLTNil-16         	484894050	         2.527 ns/op	       0 B/op	       0 allocs/op
BenchmarkCompareLTDiff-16        	172559710	         6.175 ns/op	       0 B/op	       0 allocs/op
BenchmarkCompareEQFunction-16    	183594465	         6.527 ns/op	       0 B/op	       0 allocs/op

[kentquirk]

This is failing the impi test because upstream's main branch is currently broken. Once that's fixed I'll rebase, but meanwhile I believe this is ready for review.

[kentquirk]

@TylerHelmuth ^, please

[TylerHelmuth]

@kentquirk i will start a review. Also, the collector has dropped support for 1.17, so you should be able to use generics from 1.18 now if you want.

[TylerHelmuth]

@kentquirk the TQL only supports int64 and float64 for numerics, you may be able to reduce some cases in compare.go for types the query language can't interpret natively. Technically Paths could return types like int or float32, but these are incorrect implementations of a Path.

[TylerHelmuth]

I did not remove stuff like int32 yet since it's a sunk cost, but I'm willing to. It will reduce both code and test cases if you think we should never need to worry about it.

I think we should probably stick with @bogdandrutu's normal approach of not adding something until we need it. Since the TQL explicitly states it only supports int64 and float64, I think we should drop the other int and float types until the language supports it. Sorry for the extra work!

[kentquirk]

@TylerHelmuth OK, parser now generates a CompareOp instead of strings, and I've removed support for pointers and non-64-bit type variants (and associated tests).

[TylerHelmuth]

LGTM!

[kentquirk]

@bogdandrutu I'd appreciate your review. This is passing all tests and has been reviewed and approved by @TylerHelmuth.

[jpkrohling]

@kovrus, would you like to review this one?

[evan-bradley]

Looks great overall, I really like the code comments. I noticed two minor things in the documentation.

[TylerHelmuth]

@kovrus @evan-bradley please take another look.