Tracing improvement

[guilload]

The fact that lookback period exists and defaults to 1d, but retention period of traces is index that is hardcoded in code. So this caused a bit of investigation, as there was a weird situation in Jaeger (our tracing UI) where if you searched traces as a list, it would give you traces older than one day, but if you then hit that one trace directly by ID, it would not be found due to lookback period.

[fulmicoton]

it might be useful to discuss with @trinity-1686a. They are working in parallel on an optimization that will make this lookback period trick obsolete.

[trinity-1686a]

the loopback period appear to be used in a few places, but none would be impacted by my changes I believe:

• get_services => not helped (it's a ListTerms, not a proper search)
• get_operations => not helped (it's a ListTerms, not a proper search)
• get_trace => already has the optimization, but it's only useful if we stored more than max_fetch_spans (=10_000) spans.

the thing I'm working on will only impact find_trace_ids (which gets its time bounds from jaeger iiuc). Incidentally, it will also impact find_traces as it performs a find_trace_ids followed by a stream_spans (the core logic of get_trace but the time-bounds are not derived from the loopback period)