Handle concurrent queries better

[cbizon]

See NCATSTranslator/Ordering-Organizing#43

The results caching, once complete, should address this partially. But it's odd that Sharat says that these work well sequentially but not concurrently. That suggests that there's some problem with the cache?

[maximusunc]

3b13c351-2c99-48d0-98c3-719fa9b548c9: 19 results
2eda4d97-df7e-4f9e-810b-12506f78f284: 0 results
fef324ad-cc9d-40f3-b1c8-205a5e78efda: 151 results
41b67f5a-2056-438b-bcbf-2e5b3104ffe8: 0 results
a893586e-ab8c-4b74-b72e-995f43f02d92: 0 results
0338d798-fc30-4ae5-9f4c-a5364ec6153e: 0 results
0539f51b-6f89-4efe-9850-9001cb73a911: 0 results
c12a2b3d-7646-47e6-a656-49842a043585: 0 results

We certainly want to improve our results, but we did return results for two of these queries, we didn't just miss all 8 MVP1.

I'm honestly not sure why the sequential would have given different results, unless they were run at the same time as the concurrent? I could imagine that the sequential finished before the concurrent, but then the concurrent overwrote the cache because they both missed the cache when started.

As far as why we would do worse when running concurrent I think comes down the the KPs. Aragorn can handle many many queries, but the KPs are going to run slower and/or return 429/500s when bogged down.