add option to make write lock requests interrupt other operations

[leifwalsh]

Currently (1.4.x), when a write lock request begins, it blocks behind all running read locks, and blocks new read lock requests behind it in the queue (greedy write lock). This means that write lock requests can introduce stalls, and is a general problem we've been dealing with incrementally for a while.

This adds a new option, --setParameter=forceWriteLocks=true, which makes it so that whenever a thread is waiting for a write lock, all read lock holders will treat this as an interrupt, so they bail out early (the application should retry their operations) and allow the write lock to proceed, eliminating the stall.

Whether a client agrees to be interrupted this way can be controlled with a new command, {setWriteLockYielding: false}. This sets, on a per-client connection basis, whether this thread allows itself to be interrupted by waiting write locks. To make a thread ignore waiting write locks, use db.runCommand({setWriteLockYielding: false}), and to make a thread interrupt itself when there is a pending write lock, use db.runCommand({setWriteLockYielding: true}).

The default for each new connection comes from the forceWriteLocks server parameter, which can also be set at runtime with db.setParameter('forceWriteLocks', <true|false>).