[ES] Add feature to stop Legacy Trace IDs handling in SpanReader

[Manik2708]

Which problem is this PR solving?

Fixes a part of #6458

Description of the changes

• As discussed in the comment [ES] Refactor FindTraces and GetTrace of SpanReader to make them reusable for v2 APIs #6845 (comment), legacy trace id is moved to feature gate

How was this change tested?

• Unit and Integration tests

Checklist

• I have read https://github.com/jaegertracing/jaeger/blob/master/CONTRIBUTING_GUIDELINES.md
• I have signed all commits
• I have added unit tests for the new functionality
• I have run lint and test steps successfully
  • for jaeger: make lint test
  • for jaeger-ui: npm run lint and npm run test

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.03%. Comparing base (e11fbe8) to head (6e41494).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6848      +/-   ##
==========================================
- Coverage   96.06%   96.03%   -0.04%     
==========================================
  Files         367      368       +1     
  Lines       20787    20811      +24     
==========================================
+ Hits        19969    19985      +16     
- Misses        624      630       +6     
- Partials      194      196       +2     

Flag	Coverage Δ
badger_v1	9.88% <80.00%> (+0.07%)	⬆️
badger_v2	2.05% <80.00%> (+0.07%)	⬆️
cassandra-4.x-v1-manual	14.87% <80.00%> (+0.06%)	⬆️
cassandra-4.x-v2-auto	2.04% <80.00%> (+0.07%)	⬆️
cassandra-4.x-v2-manual	2.04% <80.00%> (+0.07%)	⬆️
cassandra-5.x-v1-manual	14.87% <80.00%> (+0.06%)	⬆️
cassandra-5.x-v2-auto	2.04% <80.00%> (+0.07%)	⬆️
cassandra-5.x-v2-manual	2.04% <80.00%> (+0.07%)	⬆️
elasticsearch-6.x-v1	19.55% <100.00%> (+0.01%)	⬆️
elasticsearch-7.x-v1	19.62% <100.00%> (+0.01%)	⬆️
elasticsearch-8.x-v1	19.79% <100.00%> (+0.01%)	⬆️
elasticsearch-8.x-v2	2.05% <80.00%> (-0.04%)	⬇️
grpc_v1	10.92% <80.00%> (+0.06%)	⬆️
grpc_v2	7.98% <80.00%> (+0.07%)	⬆️
kafka-3.x-v1	10.18% <80.00%> (+0.07%)	⬆️
kafka-3.x-v2	2.05% <80.00%> (+0.07%)	⬆️
memory_v2	2.05% <80.00%> (+0.07%)	⬆️
opensearch-1.x-v1	19.67% <100.00%> (+0.01%)	⬆️
opensearch-2.x-v1	19.67% <100.00%> (+0.01%)	⬆️
opensearch-2.x-v2	2.05% <80.00%> (+0.07%)	⬆️
tailsampling-processor	0.55% <80.00%> (+0.07%)	⬆️
unittests	94.90% <100.00%> (-0.04%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[yurishkuro]

Did you see my comment #6848 (comment) ?

[Manik2708]

Did you see my comment #6848 (comment) ?

@yurishkuro Yes, but what I could understand from that comment that we need to wrap it inside init and flags. Is something more required? I can't understand about v1 components. Please can you explain this?

[yurishkuro]

If you're a user of jaeger-v1 (e.g. go run ./cmd/collector ...), how can you change the value of the feature flag? In v2 there is a CLI flag --feature-gates, but no equivalent in v1. So you need to add this CLI flag to v1 binaries (at minimum to collector, query, ingester, and remote-storage), similar to how it was done in #6790.

[Manik2708]

@yurishkuro I have given a try for implementing feature gates, please review! Is that what we needed?

[yurishkuro]

another thing that would be good to do is to add the following to some shared function and call from different mains

	settings := otelcol.CollectorSettings{}
	otelCmd := otelcol.NewCommand(settings)
	for _, cmd := range otelCmd.Commands() {
		if cmd.Name() == "featuregate" {
			otelCmd.RemoveCommand(cmd)
			command.AddCommand(cmd)
		}
	}

[Manik2708]

another thing that would be good to do is to add the following to some shared function and call from different mains

	settings := otelcol.CollectorSettings{}
	otelCmd := otelcol.NewCommand(settings)
	for _, cmd := range otelCmd.Commands() {
		if cmd.Name() == "featuregate" {
			otelCmd.RemoveCommand(cmd)
			command.AddCommand(cmd)
		}
	}

@yurishkuro Ok, so this is to provide user the information about feature gates, right? I am thinking it to add in AddFlags function of pkg/config/config.go as it is shared in all components and have the command parameter also. But the problem is it's responsibility is to add flags, so will it be ok to add a command through that function?

[yurishkuro]

no, it's not ok to abuse AddFlags for that. The pattern we have is cmd/internal/{package}/command.go that exposes func Command() *cobra.Command. So add cmd/internal/featuregate/command.go

[Manik2708]

@yurishkuro If the changes look fine, then I suggest two points in index-cleaner feature gate also:

1. Removal of pflags and following the same pattern as here.
2. Addition of featuregate command.

[yurishkuro]

then I suggest two points in index-cleaner feature gate also:

agreed - feel free to include in this PR

[Manik2708]

@yurishkuro I tried adding featuregate command in es-index cleaner, but that is failing integration tests. It might require some changes in the tests, so we can do it in a seperate PR!