Bug 916390

NLM of Gluster fails "out of the box" with RHEL and Fedora clients in the locks test -- because of the presence of firewall. Currently all blocking locks are unconditionally replied as "blocked" and grant notification is performed via callback connection to the client. Because of this even the simplest of the lock tests fail in out-of-box config of both RHEL and Fedora which have firewalls enabled by default. There are at least two changes required for better behavior.

1. Attempt a blocking NLM request in non-blocking lk(F_SETLK) first and check if lock can be obtained without any waits. If success, return success for the original RPC request and get done with. If the nonblocking lk(F_SETLK) fails, only then reply "blocked" to the original RPC request and perform lk(F_SETLKW) fop (and asynchronously notify grant via callback connection)

2. Confirm reachability of NLM client via callback channel before initiating lk(F_SETLKW). For this a simple ping RPC can be performed (or even NLMv4 TEST procedure). This offers protection against the situation where an a lock attempt from a client which has a firewall unintentionlly configured, can get granted asynchronously but never get notified at the client. Now the client can never unlock, and no other client can acquire the lock either, resulting in a deadlock.