[vParquet5] Allow up to 20 dedicated string columns and add new 3% target heuristic

[mdisibio]

What this PR does:
Doubles the max number of dedicated string columns in vParquet5 from 10 to 20. And adds target percent heuristic to tempo-cli analysis and suggest commands, similar to how we did for integers. It's not always beneficial to use all 20, so this is how we determine the optimum number. However the math works out differently such that the default cutoff is 3% for strings (whereas ints were 5%).

Because of how vParquet5 introduced dynamic columns, this is a backwards compatible change. Tempo will gracefully read/compact blocks that were previously configured for only 10.

TODO for a further improvement: right now we are taking the top N by "size" (count*length), but I suspect after all of this analysis, that top N by percent of rows could be better.

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]

[ie-pham]

LGTM - tested analyse blocks and suggest columns, the print looks good 👍 ran tempo with all the columns generated and everything works. i do agree sorting by percent might be better that its so cool to see those numbers

[stoewer]

The method DedicatedColumns.Validate() relies on the global variable maxSupportedColumns defined in block_meta.go. This variable needs to be adjusted, otherwise dedicated columns with more than 10 string columns will not pass the validation

[mdisibio]

The method DedicatedColumns.Validate() relies on the global variable maxSupportedColumns defined in block_meta.go. This variable needs to be adjusted, otherwise dedicated columns with more than 10 string columns will not pass the validation

As discussed offline, this was working because we were doing validation only against the global/static dedicated columns, not the per-tenant overrides. Added validation of the per-tenant overrides, but we decided that it would be better to treat too many columns as a warning and not a hard error. Pushed all of the plumbing to return the warning up the chain and log it.

[stoewer]

nitpick dskit has a package multierror that can be used to return an error that consists of multiple errors. Using this would allow us to have a slightly more idiomatic signature:

Suggested change

	Validate(config *Overrides) (warnings []error, err error)
	Validate(config *Overrides) (warn error, err error)

[mdisibio]

I like the current ability to inspect and log each warning independently. But no strong opinions either way. What do you think about returning a multierror directly warn MultiError, err error, then we could simplify the signature and also still inspect the individual warnings?

[mdisibio]

Thinking about this more, MultiError helps be idiomatic with returning only one error, because functions should fail fast and early. But bubbling multiple warnings up the chain seems helpful, actually I hope this is something we can do more of. So let's keep it? I was looking around to see if there was a common style for warnings, we can revisit it if we want.

[stoewer]

LGTM