Skip zero-ing primitive nulls

[tustvold]

Which issue does this PR close?

Closes #1279.

Rationale for this change

A marginal performance increase, and to gauge the appetite for these sorts of optimizations. In particular the obvious next question is, do we need to be zero-initializing the buffers to start with? I'm not entirely sure what Rust's safety rules state about uninitialized memory of POD types, are there invalid bit sequences for some types (e.g. f32), if not, why does it matter?

arrow_array_reader/read Int32Array, plain encoded, optional, half NULLs                                                                             
                        time:   [24.527 us 24.556 us 24.588 us]
                        change: [-6.4746% -5.3769% -4.4004%] (p = 0.00 < 0.05)
                        Performance has improved.
arrow_array_reader/read Int32Array, dictionary encoded, optional, half NULLs                                                                             
                        time:   [32.846 us 32.858 us 32.875 us]
                        change: [-9.1480% -8.3967% -7.9605%] (p = 0.00 < 0.05)
                        Performance has improved.

What changes are included in this PR?

Alters ScalarBuffer::pad_nulls to not zero the source location on read.

Are there any user-facing changes?

Buffers that previously contained zeros in null positions, will now contain arbitrary, but guaranteed to be valid, values

Edit: we must zero-initialize memory in general at least for floats to avoid accidentally including a signalling NaN

[sunchao]

LGTM.

I think we can completely avoid pad_nulls if we interleave definition level decoding and value decoding. This is what Spark does at the moment.

[tustvold]

This is what Spark does at the moment.

Tbh I'm surprised that is more performant, if it even is, as you're putting a branch inside the main body of the loop... Something to measure for sure 😄

[sunchao]

Well, it's the same branch for decoding levels though, it's just that we don't have to store all the decoded definition levels in a vector first, and then start decoding values.

Imagine we have 100 values to decode: first 50 is null and the rest are not-null (therefore max definition level = 1), we can:

1. read the next RLE-encoded value from definition level buffer, which is 0
2. read 50 values from the value buffer using the batch API, and also set validity bits
3. read the next RLE-encoded value from definition level buffer, which is 1
4. (assuming validity buffer is zero-initialized) increment the offset by 50

[alamb]

Thanks @tustvold and @sunchao -- arrow 10 will be even better than arrow 9!