Caching fix

[hextraza]

Caching was getting aggressively emptied because Lucene has a callback running on a loop internally that empties the cache if the IndexReader gets garbage collected. This patch caches the IndexReader per-session alongside the LRUQueryCache and slightly modifies the caching policy, which should improve the cache's behavior in prod.

[bbimber]

I dont know anything about lucene, but is caching a Reader a good idea? Does this keep file handles open?

[bbimber]

and if we cache them, should we be caching one reader instance per lucene index, rather than one per cache result?

[hextraza]

This moves to caching one IndexSearcher per lucene index path instead of one IndexReader. I moved the error handling to the caching function instead of the base of the API call which is why there are so many line changes in the most recent patch. If this passes (except for that postgres issue) we should reindex.

[bbimber]

@hextraza: i think this is probably fine. there's one thing i think we need and one question i have:

• Should we add a server shutdown listener and call close() on any open readers? not sure this practically matters but it feels like a reasonable thing.
• I think we need a hook for code to announce changes to a lucene index (like the ETL copying a new file) on JBrowseService, which would cause the cache to just clear/close that entry.

as i write this: open file handles could be a problem if unrelated code tried to update the lucene index files, right?