[EPIC] Fix safety issues in unsafe code

[andygrove]

What is the problem the feature request solves?

TL;DR when we upgrade to Rust 1.78 we discover that we have unsafe code that is really not safe and relies on undefined behavior.

The Rust standard library has a number of assertions for the preconditions of unsafe functions, but historically they have only been enabled in #[cfg(debug_assertions)] builds of the standard library to avoid affecting release performance. However, since the standard library is usually compiled and distributed in release mode, most Rust developers weren't ever executing these checks at all.

Starting with Rust 1.78, the condition for these assertions is delayed until code generation, so they will be checked depending on the user's own setting for debug assertions -- enabled by default in debug and test builds. This change helps users catch undefined behavior in their code, though the details of how much is checked are generally not stable.

Read more:

https://blog.rust-lang.org/2024/05/02/Rust-1.78.0.html#asserting-unsafe-preconditions

Here is one example of an assertion that we see when running with Rust 1.78

unsafe precondition(s) violated: slice::from_raw_parts requires the pointer to be aligned and non-null, and the total size of the slice not to exceed `isize::MAX`

Issues:

• Remove unsafe uses of copy_nonoverlapping #557

Describe the potential solution

No response

Additional context

No response

[andygrove]

These are the failing tests:

test execution::datafusion::spark_hash::tests::test_str ... thread caused non-unwinding panic. aborting.
test execution::sort::tests::test_rdxsort ... thread caused non-unwinding panic. aborting.
test parquet::util::hash_util::tests::test_crc32 ... thread caused non-unwinding panic. aborting.
test parquet::util::hash_util::tests::test_murmur2_64a ... thread caused non-unwinding panic. aborting.