The prev == it condition could only fire on the first run of the loop,
and on all subsequent runs prev (=next-1) will never be "it" anymore.
Lack of this condition changes nothing, as the following lines checking
for time distance between next and prev satisfy the same exit condition
(i.e. next-1 will be "it" only if lower_bound does not find anything,
hence next is farther away than MinVisNs).
The folding process starts at the "next" item. The nextTime variable
represents a time point before which everything should be folded, because
all items in that range are smaller than MinVis range.
The lower_bound search finds a new "next" item, which will be beyond the
nextTime range. But nextTime has origin in the previous "next" item, which
may be not the last item in the folding range. If the distance between the
new "next" and the item before is smaller than MinVis, then the new "next"
item is also folded and the folding loop must continue to run.
Note that this will likely work only when loading existing traces. In live
captures the thread name may not have yet been retrieved at the point when
timeline item insertion occurs, which will prevent the check from succeeding.
