Fix issues with AsyncBufRead::read_line and AsyncBufReadExt::lines

[hkratz]

Fixes the following issues in AsyncBufRead::read_line:

• When the future is dropped the previous string contents are not restored so the string is empty.
• If invalid UTF-8 is encountered the previous string contents are not restored.
• If an IO error occurs after read_until_internal already read a couple of bytes a debug assertion fails.
• Performance: The whole string to which read contents are appended is checked for UTF-8 validity instead of just the added bytes.

Fixes the following issues in AsyncBufReadExt:lines

• If an IO error occurs after read_until_internal already read a couple of bytes a debug assertion fails. (Fixes Lines::poll_next panics if the reader returns an error after returning data #2862)

Fixes #2862

[hkratz]

The miri error is caused by memchr + MIRIFLAGS=-Zmiri-symbolic-alignment-check with longer byte slices.

It happens even with this test on master:

#[test]
fn read_until_eof_256() {
    let mut r = Cursor::new(vec![b'x'; 256]);
    let _ = block_on(r.read_until(b'\n', &mut Vec::new()));
}

Or when running this through miri with MIRIFLAGS=-Zmiri-symbolic-alignment-check:

fn main() {
    let v=vec![b'x'; 256];
    memchr::memchr(b'a', &v);
}

Apparently we have not run into it before because our tests have short slices. Not sure what we want to do about it either. Ignore read_until-related tests for Miri or use a shorter length for IOErrorRead here to placate miri?

[taiki-e]

Thanks!