Fix a race in fusefs that can corrupt a file's size.

[asomers]

Summary

VOPs like VOP_SETATTR can change a file's size, with the vnode
exclusively locked. But VOPs like VOP_LOOKUP look up the file size from
the server without the vnode locked. So a race is possible. For
example:

1. One thread calls VOP_SETATTR to truncate a file. It locks the vnode and sends FUSE_SETATTR to the server.
2. A second thread calls VOP_LOOKUP and fetches the file's attributes from the server. Then it blocks trying to acquire the vnode lock.
3. FUSE_SETATTR returns and the first thread releases the vnode lock.
4. The second thread acquires the vnode lock and caches the file's attributes, which are now out-of-date.

Fix this race by recording a timestamp in the vnode of the last time
that its filesize was modified. Check that timestamp during VOP_LOOKUP
and VFS_VGET. If it's newer than the time at which FUSE_LOOKUP was
issued to the server, ignore the attributes returned by FUSE_LOOKUP.

PR: 259071
Reported by: Agata <[e-mail]>

Test Plan

tests added

[rmacklem]

Just fyi, when I was testing the patch I did for NFS
and was using getnanouptime(), I did have a failure
that I was not able to reproduce after switching
to nanouptime().

I'll admit I know little about the clocks, although
nanouptime() is supposed to return a more
accurate time. I did not figure out why the
less accurate time caused a failure, since a lower
resolution clock should still work. All that should
happen is attributes won't be updated because the
times are equal, more often.