client: set issue_seq (not seq) in cap release

We regularly have been observing a stall where the MDS is blocked waiting
for a cap revocation (Ls, in our case) and never gets a reply.  We finally
tracked down the sequence:

 - mds issues cap seq 1 to client
 - mds does revocation (seq 2)
 - client replies
 - much time goes by
 - client trims inode from cache, sends release with seq == 2
 - mds ignores release because its issue_seq is 1
 - mds later tries to revoke other caps
 - client discards message because it doesn't have the inode in cache

The problem is simply that we are using seq instead of issue_seq in the
cap release message.  Note that the other release call site in
encode_inode_release() is correct.  That one is much more commonly
triggered by short tests, as compared to this case where the inode needs to
get pushed out of the client cache.

Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
mon: adjust trim defaults

User testing has shown that smaller values yield better results; see #4917.
Jim's testing has had good results with even more aggressive trimming, but I
would like to do more validation yet before changing defaults.

Signed-off-by: Sage Weil <sage@inktank.com>
ceph-fuse: older libfuses don't support FUSE_IOCTL_COMPAT

Signed-off-by: Dan Mick <dan.mick@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
v0.64
Merge branch 'next'