Use state_share_anonymous_io_start for anonymous I/O conflicts with shares

There are several sources of anonymous I/O (basically any I/O not associated
with an NFS v4 stateid). Note that SETATTR of size is considered write I/O.

Any I/O with an NFS v4 special stateid.

Any NFS v3 I/O.

The all-ones NFS v4 special stateid allows READ operations to bypass share deny
read. WRITE and SETATTR(SIZE) operations are blocked by a share deny write.

With the all-zeros NFS v4 special stateid, READ is blocked by share deny read
and WRITE or SETATTR(SIZE) is blocked by share deny write.

NSF v3 READ operations are not blocked by share deny read, but NFS v3 WRITE
and SETATTR(SIZE) operations are blocked by share deny write (so this is the
same behavior as using the NFS v4 all-ones special stateid).

Note that since NFS v3 offers share reservations via NLM_SHARE, but there is
nothing like a stateid to tie the I/O to the share reservation, we must be
generous and enforce only FS v4 share deny modes against NFS v3 I/O. NLM_SHARE
with deny modes will only block NFS v4 anonymous I/O. When processing an
NFS v4 OPEN or an NLM_SHARE, deny modes always block new share reservations
with incompatible access modes. Thus, in effect, NLM_SHARE deny modes are
just advisory locks.

This behavior may be refined in the future if NFS v3 I/O is tied to an
NLM_SHARE (for example, we could assume that any I/O coming from the same
host as an applicable NLM_SHARE is using the share, otherwise, we could
conclude such I/O should conflict with any share deny modes.

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Fix a lock ABBA problem in cache_inode_lru_cleanup_try_push

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>