Fix reading partial shards

[normanrz]

This PR fixes a pretty major bug in the read code path of the sharding codec. Instead of issuing byte ranges in the form of (byte_start_offset, byte_length), the codec issues (byte_start_offset, byte_end_offset).

Fixes #2302

[d-v-b]

This PR fixes a pretty major bug in the read code path of the sharding codec. Instead of issuing byte ranges in the form of (byte_start_offset, byte_length), the codec issues (byte_start_offset, byte_end_offset).

Fixes #2302

Thanks for this fix. I'm guessing the bug slipped by because when the offset is 0, the (start, start + length) and (start, end) are identical. I don't remember offhand which convention for linear indexing we are using in the rest of the codebase, but at some point we should ensure that it's all consistent. But that's out of scope for this PR.

@TomAugspurger since you are interested in NewType usage: using NewType to brand ints as IntervalStart, IntervalEnd, IntervalLength could be a fun use of NewType.

[normanrz]

I don't remember offhand which convention for linear indexing we are using in the rest of the codebase, but at some point we should ensure that it's all consistent. But that's out of scope for this PR.

The store uses (start, length). Python slices uses (start, end). HTTP uses (start, end-1).

I now refactored the sharding codec to use (start, length) because that is what the store expects.
Would be good to get this fix out quickly!

[jhamman]

We have a small merge conflict to solve but if that is good, I can include this in the beta.1 release later today.