Support OR conditions for search tags and search tag values v2

[ie-pham]

What this PR does:
Adds OR support to the tag name and tag value autocomplete endpoints (search tags v2 / FetchTagNames / FetchTagValues).

Previously, the autocomplete path only handled a single flat list of AND-connected conditions extracted from the query filter. This PR replaces that with ExtractConditionGroups, which splits the query filter into multiple condition groups by expanding OR clauses — each group represents one AND-connected branch of the OR.

How condition splitting works

Given a query like { (.a="1" || .b="2") && .c="3" }, the filter expression is first flattened to remove nested binary operations. Then flatten group of operations are converted into condition groups. For the example above it produces two groups:

[.a="1", .c="3"]
[.b="2", .c="3"]

To avoid exponential blowup from queries with many OR clauses, the default maxConditionGroups = 100 but operators of tempo can configure this value. Queries that exceed the cap would result in an error.

Which issue(s) this PR fixes:
Fixes #

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[Copilot]

Pull request overview

Copilot reviewed 22 out of 22 changed files in this pull request and generated 3 comments.

[Copilot]

handleGetAttributeValues now rejects filter-query values that parse to match-all (e.g. {} / { true }) because ExtractConditionGroups returns an empty slice for those. Previously {} was accepted. It seems worth treating match-all filters as valid (equivalent to omitting filter-query) to avoid breaking clients that send {} by default.

Suggested change

	if len(conditionGroups) == 0 {
	if len(conditionGroups) > 1 {

[Copilot]

Pull request overview

Copilot reviewed 23 out of 23 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

tempodb/encoding/vparquet5/block_autocomplete.go:69

• In the OR/mingled fast-path, this function can return SearchTags/SearchTagValuesV2 after already calling openForSearch and setting up deferred metrics. That extra parquet open/IO work is then thrown away, and SearchTags/SearchTagValuesV2 will re-open/read again. Could we move the categorizeConditions-based fast-path checks (mingled/trivial conditionGroups) before openForSearch? This same pattern appears in the other vparquet versions and in FetchTagValues as well.

	pf, rr, err := b.openForSearch(ctx, opts)
	if err != nil {
		return err
	}

	// report metrics with defer to handle early exit
	defer mcb(rr.BytesRead())

[Copilot]

Pull request overview

Copilot reviewed 31 out of 31 changed files in this pull request and generated no new comments.