Update to Slice 2.0

[dain]

Description

This PR updates to the proposed Slice 2.0 apis.

This PR is based on #18461

Release notes

(x) This is not user-visible or docs only and no release notes are required.

[martint]

Not sure I understand this line. If there are, say, 100 shorts remaining, this would do:

ensureReadable(min(8, 200)) -> ensureReadable(8)

Also, what's the significance of Long.BYTES here? Why would this method care about having at least 8 readable bytes, assuming that's the intention?

[dain]

Absolutely agree. This is the style of the other methods in this class I had to ask @arhimondr how this code works, and this is what he said:

Hmm, it does look weird. I need to read it carefully to tell you more.
It basically tells that "at least" 8 bytes (or less if remaining bytes is less than 8" should be available
If not available - it will read an entire encryption / compression block

I think we all agree it need some renaming

[martint]

Same comment as above.

[dain]

same as above

[martint]

It probably doesn't matter, but be aware that this is not equivalent to the old code in terms of semantics and performance.

[electrum]

We could add an update() method that accepts a long

[dain]

Yep, I agree to both comments. The code should be fine as this is only used during spilling, and only used as a checksum.

[martint]

Should we add this to Slice?

[dain]

We could add this to Slices. I tooks a quick look at the code base, and there are like 20ish places that do this.

[martint]

Do we need to cache this one-int buffer (in the class, or for the whole method) to avoid potentially reallocating on every boundary? Not sure how often remaining < Integer.BYTES is true.

[dain]

I added tempBuffer8 as a field variable and use it in int[] and long[] methods

[martint]

Slice.getByte() and Slice.getByteUnchecked() should be equivalent now, no?

[dain]

getByte performs a bounds check on the Slice's view of the underlying byte[].

[electrum]

We could add an update() method that accepts a long