ARROW-11045: [Rust] Fix performance issues of allocator

[jorgecarleitao]

This PR addresses a performance issue in how we allocate and reallocate the MutableBuffer by migrating the relevant parts of rust's std alloc lib into this crate.

Problem

The following is the result of 4 runs:

mutable                 time:   [929.26 us 931.88 us 935.42 us]                    
mutable prepared        time:   [1.0682 ms 1.0693 ms 1.0709 ms]                              
from_slice              time:   [4.4857 ms 4.5043 ms 4.5247 ms]                        
from_slice prepared     time:   [1.4358 ms 1.4406 ms 1.4467 ms]                                 

1. start with an empty MutableBuffer and grow it (realloc + memcopy)
2. start with a mutable with the correct capacity and grow (i.e. memcopy)
3. do the same as 1. with a Vec<u8> (realloc + memcopy) and at the end of all use Buffer::from (a memcopy)
4. same as 2 and at the end of all use Buffer::from (memcopy to vec + memcopy to Buffer)

The fact that there is no difference between 1 and 2 but a 3.5x difference between 3 and 4 shows that we are doing something wrong. The fact that 1 is as fast as 2 shows that we are doing something wrong.

This PR

This PR rewrites our current allocator code to a code very close to the code used by std allocator. The core reason we do this is that we benefit from cache-line aligned allocated buffers ref, but Rust's custom allocator's API is unstable (and thus only available in nightly).

The code in this PR is not very complex and I assume that it was already well though through from rust's std team. I did the necessary modifications for our use-case:

• always allocate aligned
• always allocate in chunks of 64 bytes
• always allocate initialized to zero (std::alloc::alloc_zeroed)

The main benefit of this is that we can use MutableBuffer, BooleanBufferBuilder and BufferBuilder in the same way as we would use Vec<u8>, Vec<bool> and Vec<T: Primitive> respectively without having to rely on unsafe code to efficiently build buffers.

The performance difference is mostly present in variable-sized buffers, such as strings.

Benchmarks for take:

git checkout master
cargo bench --bench take_kernels --features simd
git checkout alloc
cargo bench --bench take_kernels --features simd

benchmark	variation (%)
take i32 nulls 1024	5.9
take i32 1024	4.4
take i32 512	2.1
take str 512	2.1
take i32 nulls 512	1.6
take str 1024	1.0
take bool nulls 1024	-1.5
take bool nulls 512	-2.4
take bool 512	-6.8
take bool 1024	-8.3
take str null values 1024	-10.6
take str null values null indices 1024	-18.9

Builder benches:

bench_primitive         time:   [967.71 us 969.06 us 970.62 us]                            
                        thrpt:  [4.0245 GiB/s 4.0310 GiB/s 4.0366 GiB/s]
                 change:
                        time:   [-4.3022% -3.2064% -2.2317%] (p = 0.00 < 0.05)
                        thrpt:  [+2.2826% +3.3126% +4.4956%]
                        Performance has improved.
Found 8 outliers among 100 measurements (8.00%)
  1 (1.00%) low mild
  3 (3.00%) high mild
  4 (4.00%) high severe

bench_bool              time:   [2.0547 ms 2.0823 ms 2.1163 ms]                        
                        thrpt:  [236.27 MiB/s 240.11 MiB/s 243.35 MiB/s]
                 change:
                        time:   [-25.302% -24.178% -22.857%] (p = 0.00 < 0.05)
                        thrpt:  [+29.629% +31.887% +33.873%]
                        Performance has improved.
Found 13 outliers among 100 measurements (13.00%)
  5 (5.00%) high mild
  8 (8.00%) high severe

[github-actions]

https://issues.apache.org/jira/browse/ARROW-11045