Seems reasonable enough to me. I would be happy to see this.

@joshtriplett I worked on implementing read_buf_exact in #7130, but encountered an issue with resizable buffers like Vec. I'd like to hear your thoughts on this.

Since these buffers have infinite capacity, it's a misuse of the function to call it like read_buf_exact(&mut vec). So the function signature should be something like read_buf_exact(buff, len) so the expected amount is explicitly passed to the function, but this makes it a less attractive API and feature to be added to AsyncReadExt.
We could also put this under tokio-util, next to read_buf, but then it's a harder to find API.

Having it in a less prominent place would be OK if necessary, though it might be nice to have a cross-reference to it from read_buf if so.

The use case I had in mind involves a sized uninitialized buffer, using https://doc.rust-lang.org/std/sync/struct.Arc.html#method.new_uninit_slice . For that purpose, it would be more convenient if the API relies on the existing length. However, I understand that that would be less convenient for growable buffers.

This seems like something best handled with either 1) two APIs or 2) a BufMutLen trait or similar, implemented by buffers with a fixed size, not implemented by buffers with an unlimited size, and possibly a LimitedBuf wrapper that clamps the size of any buffer and implements BufMutLen. That option would allow passing a limited buffer directly, or adding a length to an unlimited buffer temporarily for the call.

I've now written a PR for a tokio_util function read_exact_arc. That will solve the problem that originally motivated this. (read_buf_exact would probably still be useful, though.)