query_namespaces performance improvements

[jhamon]

Problem

Want to improve the performance of the rest implementation of query_namespaces

Solution

• Add pytest-benchmark dev dependency and some basic performance tests to interrogate the impact of certain changes. For now these are only run on my local machine, but in the future these could potentially be expanded into an automated suite.
• Pass _preload_content=False to tell the underlying generated code not to instantiate response objects for all the intermediate results.
• Use ThreadPoolExecutor instead of older ThreadPool implementation from multiprocessing. This involved some changes to the generated code, but the benefit of this approach is that you get back a concurrent.futures.Future instead of an ApplyResult which is much more ergonomic. I'm planning to extract the edited files out of the code gen process very shortly, so there shouldn't be a concern about modifying generated files in this case. I gated this approach behind a new kwarg, async_threadpool_executor, that lives alongside async_req; eventually I would like to replace all usage of async_req's ThreadPool with ThreadPoolExecutor to bring the rest and grpc implementations closer together, but I can't do that in this PR without creating a breaking change.

The net effect of these changes seems to be about ~18% performance improvement.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update
• Infrastructure change (CI configs, etc)
• Non-code change (docs, etc)
• None of the above: (explain here)

[austin-denoble]

Very nice work. Extracting the generated classes out so we can actually modify them is great.

The net effect of these changes seems to be about ~18% performance improvement.
🎉

[rohanshah18]

Great work, LGTM!