wasi: Handle read(0) with file streams

[elliottt]

The read method on streams should support a size argument of zero, to test if the stream is still open. However, the implementation of read for open files was unconditionally treating a read that would return zero bytes as an indication that the stream was closed.

This PR fixes this bug by handling a read(0) as an explicit test to see if the current position is at the end of the file.

[alexcrichton]

I'm a little hesitant to provide such a strong guarantee that a read of size 0 is effectively a stat on all files. Would it work to instead pass the read size to read_result and don't return Closed if the read size is zero?

[elliottt]

I don't think that works, as cap_std::fs::File::read_at won't signal any error for a read at the end of a file, of 0 bytes. That means that a read(0) will succeed indicating that it read zero bytes, and a subsequent non-zero read will fail because the file is closed. I agree that this is a bit heavyweight, but I think something like it is necessary to satisfy this part of the streams contract:

wasmtime/crates/wasi/wit/deps/io/streams.wit

Lines 51 to 53 in 7a91375

	/// When the caller gives a `len` of 0, it represents a request to
	/// read 0 bytes. If the stream is still open, this call should
	/// succeed and return an empty list, or otherwise fail with `closed`.

[alexcrichton]

I think it still satisfies the contract though because the streams interface is supposed to be super general and it's always possible for a generic stream to get disconnected at any time. For example if you do a zero-length read on a socket it may say it's ready only for the next read to say it's closed.

[elliottt]

Fair enough. I've pushed a change to that effect.