wasi-common/yanix: fix FreeBSD support

[valpackett]

• there is no O_DSYNC, define that to zero, same with O_RSYNC
  • can't have another top level cfg for not(…) in the bitflags because Constants cannot be cfg-gated multiple times bitflags/bitflags#137 but cfg_if is better anyway (platforms only listed once)
• d_fileno for inode

[kubkon]

Hey! Thanks for the PR! The changes look great to me, just a couple of nitpicks.

[kubkon]

Now that I look at how we use O_RSYNC in wasi-common, I think we've got a bug since regardless what is specified in yanix, i.e., whether O_RSYNC is defined or not, we always overwrite it with a substitution O_RSYNC = yanix::file::OFlag::SYNC: see sys/unix/bsd/host_impl.rs#4.

This is not directly relevant to changes introduced in this PR, but I thought it's good to point that out, and fix in a subsequent PR.

[sunfishcode]

The linked comment says that defining O_RSYNC to 0 is ok because they use rangelocks. In WASI, we don't have range locks, so that assumption may not be valid.

If FreeBSD doesn't support O_RSYNC or O_DSYNC, we should consider implementing them manually -- by calling fdatasync etc. ourselves as needed. If that's infeasible or awkward, we should consider removing them from WASI altogether, so that applications don't rely on them if they aren't reliable.

[kubkon]

The linked comment says that defining O_RSYNC to 0 is ok because they use rangelocks. In WASI, we don't have range locks, so that assumption may not be valid.

If FreeBSD doesn't support O_RSYNC or O_DSYNC, we should consider implementing them manually -- by calling fdatasync etc. ourselves as needed. If that's infeasible or awkward, we should consider removing them from WASI altogether, so that applications don't rely on them if they aren't reliable.

Hmm, that's a good catch! I missed the fact that the reason O_RSYNC is set to 0 is because FreeBSD uses range locks.

I reckon trying to implement them manually for our use sounds good, and if impossible, dropping it from WASI is within reason as well (as we might have to do with symlinks for instance due to the differences between *nixes and Windows).

[valpackett]

Maybe defining them to O_SYNC is a safe-and-easy option..?

[sunfishcode]

Yes, defining O_DSYNC to O_SYNC on hosts that lack O_DSYNC looks like a reasonable solution.

[sunfishcode]

To elaborate, while the comment here says that defining O_DSYNC to O_SYNC is wrong in intent, that relies on an assumption of what the intent is. In wasi-common, we can't make such assumptions, so we have to be conservative.

[valpackett]

Updated with O_SYNC, nitpicks, fixes for the new any(target_os = "macos", target_os = "linux") stuff in the runtime, and posix_fadvise support.

test result: ok. 109 passed; 0 failed; 40 ignored; 0 measured; 0 filtered out

[sunfishcode]

Looks good, thanks!