RUBY-578: concurrency rsclient

RUBY-578
These changes address an issue in the driver manifested when more than one thread would try to refresh concurrently.  The changes are split into 4 commits:

1. Minor changes to pool manager: I cleaned up a few style things, extra variables, and extra private keyword.

2. Pool manager members set: Previously, the members set in the pool managers was only ever updated in a mutex, but there was no lock around the reading of members, thus making it possible for one thread to be updating the set while another was reading it.  The changes to the pool managers has an immutable, read-only members set and a mutable local set in the connect method.  The latter is used when connecting.  It then is swapped in for the members set instance variable after the connect has finished.

3. Updates to node: Updates were also made to node so that there is an instance variable for max bson or message size that can be read.  The way it was implemented before, it was possible that a node would try to connect when getting its config to return those values.  This presented a problem when a node in the read-only, immutable members set of pool manager would try to change itself by updating its config.

4. Cleanup rs and sharded clients of superfluous mutexes: Remove some extra mutexes in mongo_sharded_client and mongo_replica_set_client.

5. Refresh method in rs client: There is now a connect mutex around a call to refresh a pool manager.  The mutex was removed in sync refresh but this won't be a problem because the mutex in hard_refresh ensures that only one thread can refresh or connect at a time.  The refresh version is checked right before the thread tries to get the refresh lock so that it won't refresh if another thread refreshed while it was waiting for the lock.