Miri should artifically shorten some reads/writes

[RalfJung]

The issue in #4367 would likely have been found a lot faster if Miri artificially shortened reads/writes sometimes. I'm thinking of a heuristic like, with 50% probability only try to read/write half as much as was requested. (But we probably need to still read/write at least 1 byte -- 0-byte reads have different semantics IIRC?)

Cc @tiif @Noratrieb

[tiif]

If we have this feature, it'd be helpful for us to figure out which part of the test might fail spuriously. But I haven't had any ideas on how to make the test better. (I have an idea below)

This kind of failure also can also happen for other writes in std.

If this method consumed n > 0 bytes of buf it must return Ok(n). If the return value is Ok(n) then n must satisfy n <= buf.len(). A return value of Ok(0) typically means that the underlying object is no longer able to accept bytes and will likely not be able to in the future as well, or that the buffer provided is empty.

EDIT: Maybe if we write n bytes, we should accept the value from 0 to n as the number of bytes written instead of only n?

[RalfJung]

This kind of failure also can also happen for other writes in std.

What do you mean, "other writes"? That's the writes I am talking about.

In the end this is about the underlying libc functions read/write though, not about the public functions in std.

[tiif]

I initially thought the failure can only happen in tokio's write.

But then I figured out the failure can also happen for other non-tokio write.