RowSet.subIndexByPos bug

[rcaudy]

This was discovered when exercised by a demo @devinrsmith is building. The following (groovy) reproducer simulates what he encountered:

t = emptyTable(6).update("II=ii")
t.setRefreshing(true)
c=t.countBy("Count", "II").sortDescending("Count").update("K=k")
s = c.slice(5, Long.MAX_VALUE)

(Ticking sort uses a large offset from 0 when building its initial row set in order to allow for data to tick in before existing data without shifting immediately.)

The following should illustrate the specifics of the bug as exercised by the above table operations:

println c.getRowSet()
{1073741821-1073741826}

println c.getRowSet().innerSet
io.deephaven.engine.rowset.impl.singlerange.IntStartIntDeltaSingleRange@16626b51
println c.getRowSet().innerSet.unsignedIntStart
1073741821
println c.getRowSet().innerSet.unsignedIntDelta
5

println s.getRowSet().innerSet
io.deephaven.engine.rowset.impl.singlerange.IntStartLongDeltaSingleRange@63cd4dbb
println s.getRowSet().innerSet.unsignedIntStart
1073741826
println s.getRowSet().innerSet.delta
9223372036854775801

The operation that is going awry is:

c.getRowSet().subsetByPositionRange(5, Long.MAX_VALUE)

Meaning there must be a bug in:
io.deephaven.engine.rowset.impl.singlerange.SingleRange#ixSubindexByPosOnNew

I think the bug is at the end:

        return make(
                Math.max(rangeStart() + startPos, rangeStart()),
                Math.min(rangeStart() + endPos, rangeEnd()));

This doesn't contemplate wraparound. We could fix it with this change:

        return make(
                Math.max(rangeStart() + startPos, rangeStart()),
                Math.min(Math.max(rangeStart() + endPos, Long.MAX_VALUE), rangeEnd()));

That is, if rangeStart() + endPos wraps around, just clamp to Long.MAX_VALUE.

[rcaudy]

Note that I freely acknowledge that the proposed solution late last night was half-baked, since it would be inappropriate in the normal range of values.