Investigate need for markThreadIdle with adaptive service executor

Each of the six runs ramps up from 0 to 500 client threads each attempting to do as many as 1000 updates per second. The system reaches CPU saturation at about 38 k/s, so of course we expect to see queuing, and to see the client open 500 connections. The six runs are respectively

1. synchronous, 3.5.11
2. synchronous, 3.5.11 + SERVER-28599
3. synchronous, 3.5.11 with calls to markThreadIdle suppressed
4. adaptive, 3.5.11
5. adaptive, 3.5.11 + SERVER-28599
6. adaptive, 3.5.11 with calls to markThreadIdle suppressed

Comparing runs 4, 5, and 6 we see the impact of markThreadIdle in 4 with the adaptive service executor, fixed by either change in 5 and 6.

Once the current performance issue with markThreadIdle has been addressed by SERVER-28599, we should investigate whether and where markThreadIdle should be called in the adaptive case. This should be evaluated using the tests from SERVER-16773 that led to the implementation of markThreadIdle for the synchronous case.