[storage][v2] Add reader adapter that just exposes the underlying v1 reader

[mahadzaryab1]

Which problem is this PR solving?

• Towards Implement Storage API v2 that operates on OTLP batches #5079

Description of the changes

• This PR implements the v2 spanstore.Reader interface in the factory adapter through the TraceReader, which is currently just a wrapper around the v1 spanstore.Reader. The TraceReader provides a function GetV1Reader that exposes the underlying v1 reader which will be used in [v2][storage] Implement read path for v2 storage interface #6170.

How was this change tested?

• Added unit tests for new functions

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: yarn lint and yarn test

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.43%. Comparing base (939d7c3) to head (5d13a31).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6221   +/-   ##
=======================================
  Coverage   96.43%   96.43%           
=======================================
  Files         354      355    +1     
  Lines       20134    20157   +23     
=======================================
+ Hits        19416    19439   +23     
  Misses        530      530           
  Partials      188      188           

Flag	Coverage Δ
badger_v1	8.31% <ø> (ø)
badger_v2	1.67% <0.00%> (-0.01%)	⬇️
cassandra-4.x-v1	14.39% <ø> (ø)
cassandra-4.x-v2	1.61% <0.00%> (-0.01%)	⬇️
cassandra-5.x-v1	14.39% <ø> (ø)
cassandra-5.x-v2	1.61% <0.00%> (-0.01%)	⬇️
elasticsearch-6.x-v1	18.60% <ø> (ø)
elasticsearch-7.x-v1	18.68% <ø> (ø)
elasticsearch-8.x-v1	18.85% <ø> (ø)
elasticsearch-8.x-v2	1.67% <0.00%> (+<0.01%)	⬆️
grpc_v1	9.44% <ø> (ø)
grpc_v2	6.98% <0.00%> (-0.02%)	⬇️
kafka-v1	8.88% <ø> (ø)
kafka-v2	1.67% <0.00%> (-0.01%)	⬇️
memory_v2	1.67% <0.00%> (-0.01%)	⬇️
opensearch-1.x-v1	18.73% <ø> (ø)
opensearch-2.x-v1	18.73% <ø> (+<0.01%)	⬆️
opensearch-2.x-v2	1.67% <0.00%> (+<0.01%)	⬆️
tailsampling-processor	0.46% <0.00%> (-0.01%)	⬇️
unittests	95.35% <100.00%> (+<0.01%)	⬆️

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.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests
• JS Bundle Analysis - Avoid shipping oversized bundles

[yurishkuro]

at some point we would need to implement these methods, because as soon as we start upgrading query subcomponents to use v2 storage api directly (e.g. the apiv3 handler, the easiest to upgrade since it already returns OTLP formats) they will be blocked on this implementation for v1-only backends.

[mahadzaryab1]

@yurishkuro what would these implementations look like?

[yurishkuro]

you would call the underlying v1 reader to retrieve the trace and then convert the result into OTLP data model