Honor length in Tuple.fromBytes if provided

[alecgrieser]

In Tuple unpack, we were looping until the end of the array rather than to the end of where the user specified. This fixes that. It now passes the little quick test I added within Tuple.java, but testing this more thoroughly would probably require more work in other places.

It also looks like the TLS related network options that were just added to fdb.options weren't added to the generated.go file, so I fixed that (in a separate commit).

This closes #362.

[ajbeamon]

What happens if end is past the end of the bytes array?

[alecgrieser]

In that case, you will get an ArrayIndexOutOfBoundsException on line 351 of TupleUtil when it tries do decode the value out of range:

foundationdb/bindings/java/src/main/com/apple/foundationdb/tuple/TupleUtil.java

Line 351 in a799d2a

int code = rep[pos];

Arguably, the correct thing is for this method (unpack) to do bounds checking early and then exit right then. I could add that, if we want.

[ajbeamon]

What does the rest of the Tuple layer do? If it behaves similarly to this, we can leave it and address it later as a whole if we want.

[alecgrieser]

I believe it generally does bounds checking at the last possible moment (i.e., when it gets the ArrayIndexOutOfBoundsException. That leads to another problem, which is that the decode logic for, say, floats will not necessarily do the right thing. For example:

Tuple.fromBytes(Tuple.from(3.14f).pack(), 0, 3)

will return (3.14f) rather than throwing an error (because it doesn't check that the item is entirely located within the correct range). I think all of the fixed length types are like that, but the variable length things will stop before hitting their terminator.

[ajbeamon]

Ok, as we discussed a bit offline, I think we'll go ahead and merge this. If we want, we can raise a new issue to address the concern you just raised.