CDRIVER-619 fail fast after TLS socket hangup

The test had been querying collections with random names like
$cmd.sys.inprog_12345, which returned the currentOp, the same as
$cmd.sys.inprog, on legacy servers, but not since SERVER 7775.
Now if we query "$cmd.sys.inprog" exactly, the test still works.

ANSI C warnings

CDRIVER-513 missing docs

The EXIT macro is a return statement.

New configure flag to enable/disable shared memory performance counters.

# By Jason Carey (hanumantmk)
# Via Jason Carey (hanumantmk)
* pr-193:
  prerelease version

Conflicts:
	CMakeLists.txt
	build/autotools/Versions.m4

Besides being a correct use of libmongoc, it also fixes building with
"./configure --disable-shared --enable-static" and clang on Mac.

* pr-194:
  CDRIVER-580: fsync or j in write concern imply GLE
  Use write concern macros instead of magic numbers

CDRIVER-560: Include private header in mongoc-client-pool.c.

Fixes CDRIVER-603.

Signed-off-by: Jason Carey (hanumantmk) <jcarey@argv.me>

The fsync and journal options should imply a GLE; however, they logically conflict with w=0 and w=-1, so the write concern should be considered invalid with errors raised during URI parsing or write command execution.

If fsync or journal have been specified (true or false), they should be included in the write concern BSON.

I was seeing deadlocks in the client when it lost contact with mongo.
The client was getting stuck on a futex in mongoc_client_pool_pop(),
specifically

    mongoc_cond_wait(&pool->cond, &pool->mutex);

and never making any progress even when mongo came back on-line.

This problem was introduced by commit a8c1da45

 ("Client pool tries to
repair unhealthy connections...") which started shutting down excess
connections, i.e where there were more connections than minPoolSize.

As part of this it would also decrement pool->size. This all happens in
mongoc_client_pool_push()

The problem here was that if you had a single active connection and a
minPoolSize of 0 (the default) then it would try to remove the oldest
client from the queue (in this case there wasn't one) and then decrement
pool->size.

pool->size would now be 0.

Then we move into the trying to deal with duff connections part of the
above commit. In this case, with no working mongo, it will want to
destroy this connection, which it does but it will also again decrement
pool->size, which now equals -1, except pool->size is a unit32_t

Then in mongoc_client_pool_pop() we have this check

     if (pool->size < pool->max_pool_size) {

pool->size is now some _large_ number, UINT32_MAX perhaps. and so that
evaluates to false and then we move to the else branch which then
executes

    mongoc_cond_wait(&pool->cond, &pool->mutex);

and this is where we get stuck. It thinks there is too many connections
and at the same time nothing is ever going to be returned to the queue
(we only had a single active connection) and even we did return a
connection to the pool, UINT32_MAX - 1 is still likely going to be >
pool->max_pool_size.

So to avoid this problem we simply don't want to try and remove
connections from the queue that don't exist and more importantly don't
decrement pool->size when we don't actually remove an old connection.

After this change, I can start mango, start the client, kill mongo,
client shows errors, but keeps trying to re-connect, restart mongo and
client is then happy again.

Signed-off-by: Andrew Clayton <andrew@digital-domain.net>

Closes #187

Commit a8c1da45

 ("Client pool tries to repair unhealthy connections...")
introduced more code to mongoc_client_pool_push() operating on the
connection pool. However locking was missing on the first if () section
which deals with various aspects of the connection pool and requires
locking.

Protect the if () with a mongoc_mutex_lock/unlock using pool->mutex.

Signed-off-by: Andrew Clayton <andrew@digital-domain.net>

Avoid the use of cluster_try_sendv for healthy and unhealthy clusters.
It just needlessly avoids reconnects and persists the same errors.

False safe/journal values should be explicitly set on the write concern. Additionally, w=1 should not be parsed as MONGOC_WRITE_CONCERN_W_DEFAULT, since the driver would then omit it from the write concern and allow a different server-side default to be applied.

Closes #195