virtual_file: take a Slice in the read APIs, eliminate read_exact_at_n, fix UB for engine std-fs

[problame]

part of #7418

I reviewed how the VirtualFile API's read methods look like and came to the conclusion that we've been using IoBufMut / BoundedBufMut / Slice wrong.

This patch rectifies the situation.

Change 1: take tokio_epoll_uring::Slice in the read APIs

Before, we took an IoBufMut, which is too low of a primitive and while it seems convenient to be able to pass in a Vec<u8> without any fuzz, it's actually very unclear at the callsite that we're going to fill up that Vec up to its capacity(), because that's what IoBuf::bytes_total() returns and that's what VirtualFile::read_exact_at fills.

By passing a Slice instead, a caller that "just wants to read into a Vec" is forced to be explicit about it, adding either slice_full() or slice(x..y), and these methods panic if the read is outside of the bounds of the Vec::capacity().

Last, passing slices is more similar to what the std::io APIs look like.

Change 2: fix UB in virtual_file_io_engine=std-fs

While reviewing call sites, I noticed that the io_engine::IoEngine::read_at method for StdFs mode has been constructing an &mut[u8] from raw parts that were uninitialized.

We then used std::fs::File::read_exact to initialize that memory, but, IIUC we must not even be constructing an &mut[u8] where some of the memory isn't initialized.

So, stop doing that and add a helper ext trait on Slice to do the zero-initialization.

Change 3: eliminate read_exact_at_n

The read_exact_at_n doesn't make sense because the caller can just

1. slice = buf.slice() the exact memory it wants to fill
2. slice = read_exact_at(slice)
3. buf = slice.into_inner()

Again, the std::io APIs specify the length of the read via the Rust slice length.
We should do the same for the owned buffers IO APIs, i.e., via Slice::bytes_total().

Change 4: simplify filling of PageWriteGuard

The PageWriteGuardBuf::init_up_to was never necessary.
Remove it. See changes to doc comment for more details.

---

Reviewers should probably look at the added test case first, it illustrates my case a bit.

[github-actions]

2940 tests run: 2823 passed, 0 failed, 117 skipped (full report)

---

Code coverage* (full report)

• functions: 32.7% (6912 of 21137 functions)
• lines: 50.1% (54174 of 108142 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
9fa4f47 at 2024-06-27T18:57:04.856Z :recycle:}

[VladLazar]

+1 for the Slice based api