The analyzeShardKey command can take a long time to run when chunks are being moved among shards, and this is partly due to shardVersionRetry() retrying for up to kMaxNumStaleVersionRetries times, which is hard-coded to 10. The great number of retries results in test runs where multiple executions of analyzeShardKey can trigger the Evergreen hang detector. We want to limit the number of retries so that analyzeShardKey fails fast (failing due to data movement is an acceptable error in analyze_shard_key.js).

Add an overriding lower maximum number of retries for StaleVersion as a server parameter that analyzeShardKey can use when calling shardVersionRetry(). When this new server parameter is set to 0 (default), shardVersionRetry() should use the default behavior (retry kMaxNumStaleVersionRetries times). When the server parameter is set to a positive number, use this number as the maximum number of retries (but still no more than kMaxNumStaleVersionRetries).