fusefs: Fix a bug during VOP_STRATEGY when the server changes file size

[asomers]

Summary

If the FUSE server does something that would make our cache incoherent,
we should print a warning to the user. However, we previously warned in
some situations when we shouldn't, such as if the file's size changed on
the server _after_ our own attribute cache had expired. This change
suppresses the warning in cases like that. It also moves the warning
logic to a single place within the code.

PR: 256936
Reported by: Agata <[e-mail]>
Tested by: Agata <[e-mail]>, [e-mail]
MFC after: 2 weeks

fusefs: fix a recurse-on-non-recursive lockmgr panic

fuse_vnop_bmap needs to know the file's size in order to calculate the
optimum amount of readahead. If the file's size is unknown, it must ask
the FUSE server. But if the file's data was previously cached and the
server reports that its size has shrunk, fusefs must invalidate the
cached data. That's not possible during VOP_BMAP because the buffer
object is already locked.

Fix the panic by not querying the FUSE server for the file's size during
VOP_BMAP if we don't need it. That's also a a slight performance
optimization.

PR: 256937
Reported by: Agata <[e-mail]>
Tested by: Agata <[e-mail]>
MFC after: 2 weeks

fusefs: Fix a bug during VOP_STRATEGY when the server changes file size

If the FUSE server tells the kernel that a file's size has changed, then
the kernel must invalidate any portion of that file in cache. But the
kernel can't do that during VOP_STRATEGY, because the file's buffers are
already locked. Instead, proceed with the write.

PR: 256937
Reported by: Agata <[e-mail]>
Tested by: Agata <[e-mail]>
MFC after: 2 weeks

Test Plan

tests added

[asomers]

I didn't realize that the revision title was set wrong at first. Phabricator can handle multi-commit diffs, but apparently it sets the title based on the first commit, and in this case that wasn't the most important.