4.x: AbstractVectorToArrayCodec.decode throws on a null or empty buffer

[nikagra]

Found while writing FloatVectorToArrayCodecTest under DRIVER-1000, where both behaviours are pinned in passing tests.

1. A null or empty buffer throws instead of returning null.

public ArrayT decode(@Nullable ByteBuffer bytes, @NonNull ProtocolVersion protocolVersion) {
  if (bytes == null || bytes.remaining() == 0) {
    throw new IllegalArgumentException(
        "Input ByteBuffer must not be null and must have non-zero remaining bytes");
  }

TypeCodec#decode documents the opposite:

Null or empty buffers should be gracefully handled and no exception should be raised; they should be considered as the equivalent of a NULL CQL value […]

GettableByIndex#get is codec.decode(getBytesUnsafe(i), …) and getBytesUnsafe returns null for a CQL NULL, so every row with a NULL vector<float, n> cell throws out of row.get("v", ExtraTypeCodecs.floatVectorToArray(n)).

Both neighbours disagree with this codec: VectorCodec.decode returns null, and the copy-paste ancestor AbstractPrimitiveListToArrayCodec.decode returns newInstance(0).

2. A short buffer surfaces a raw BufferUnderflowException.

int length = this.cqlType.getDimensions();
...
for (int i = 0; i < length; i++) { deserializeElement(input, array, i, protocolVersion); }

bytes.remaining() is never compared against length * sizeOfComponentType(), so a truncated or corrupt server value reaches application code as an unchecked JDK exception with no message. VectorCodec throws IllegalArgumentException naming the expected and observed sizes for the identical input, and VectorCodecTest.should_throw_on_decode_if_too_few_bytes pins it.

Both halves are in AbstractVectorToArrayCodec.decode and land together. Neither is covered by #1088, which is about two genuinely unreachable branches.