Fix wasi::fs::OpenOptions to imply write when append is on

[kawamuray]

This PR fixes a bug in OpenOptions of wasi platform that it currently doesn't imply write mode when only append is enabled.
As explained in the doc of OpenOptions#append, calling .append(true) should imply .write(true) as well.

Reproduce

Given below simple Rust program:

use std::fs::OpenOptions;
use std::io::Write;

fn main() {
    let mut file = OpenOptions::new()
        .write(true)
        .create(true)
        .open("foo.txt")
        .unwrap();
    writeln!(file, "abc").unwrap();
}

it can successfully compiled into wasm and execute by wasmtime runtime:

$ rustc --target wasm32-wasi write.rs
$ ~/wasmtime/target/debug/wasmtime run --dir=. write.wasm 
$ cat foo.txt 
abc

However when I change .write(true) to .append(true), it fails to execute by the error "Capabilities insufficient":

$ ~/wasmtime/target/debug/wasmtime run --dir=. append.wasm
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 76, kind: Other, message: "Capabilities insufficient" }', append.rs:10:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: failed to run main module `append.wasm`
...

This is because of lacking "rights" on the opened file:

$ RUST_LOG=trace ~/wasmtime/target/debug/wasmtime run --dir=. append.wasm 2>&1 | grep validate_rights
 TRACE wasi_common::entry                                  >      | validate_rights failed: required rights = HandleRights { base: fd_write (0x40), inheriting: empty (0x0) }; actual rights = HandleRights { base: fd_seek|fd_fdstat_set_flags|fd_sync|fd_tell|fd_advise|fd_filestat_set_times|poll_fd_readwrite (0x88000bc), inheriting: empty (0x0) }

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @kennytm (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[joshtriplett]

Looks good to me. A libs implementer should review as well, but I think this is reasonable.

[kawamuray]

Hi @kennytm ,
do you think you can find some time for reviewing this? Or would I better try finding someone else as a reviewer?

[kennytm]

🤔 i'm not a libs implementer though

[kawamuray]

i'm not a libs implementer though

oh! I thought you're a right person to review this as rust-highfive selected you automatically.. Thanks for your response anyway.

Let me try mentioning another person from https://www.rust-lang.org/governance/teams/library this list then.

[kawamuray]

r? @KodrAus

[KodrAus]

Looks good to me! @bors r+ rollup

[bors]

📌 Commit 165a6e5 has been approved by KodrAus