Optimise trace table schema for storage

[ankitnayan]

We have multiple tables to store trace data for different needs. We should only store relevant field of trace in each table to optimise the storage needs.

[makeavish]

Tested a new index on signoz_index_v2 table to fetch trace.
Without index:

1.43B rows scanned - (all the rows) at speed of 36M rows/s and took 40s

With index:

8M rows scanned at speed of 1.5M rows/s and took 6s (This was best perf achieved after playing around with bloom filter vars).
Query time linearly(by factor less than 1) scales with data. Results: on 200M dataset it took 2.8s, on 400M dataset it took 4.2s and on 1.4B data set it took 6s.

On signoz_spans table it took 0.8s and only scanned 34k rows at speed of 41k rows/s.

[makeavish]

@ankitnayan Can we introduce a new ID named sTraceID (short for signoz traceID) which will be based on timestamp(kuid) similar to ID in logs.
We will replace traceID with sTraceID everywhere and we can use min max index. This will improve performance and we can deprecate signoz_spans