There is already a ThreadPool class, but it support only the scheduling of Future objects without a few features that Query Parallelism would rely on:

1. Renameable (so that logs triggered by a parallel stream for the thread bound to conn56 are printed as conn56-1, conn56-2, etc)
2. Server parameter to control maximum number (given the 127 tickets granted to Query by the WT engine, default size would be 64)
3. Single acquire() API that returns N threads in one shot, we don't want to schedule work that would be not served immediately by
   1. not enough idle threads in the pool or
   2. not enough tickets in the ticket granting pool
4. FTDC metric to report current number, in use, idle