Audit uncacheable queries (comments, text search) and see if timestamp param will do

[ryanrdoherty]

While trying to find the source of a recent bug (see #127), it was noticed that we run a LOT of service calls to SOLR for text search because the process query is marked uncacheable. The thinking was probably that SOLR could be updated at any time and users would always want to see the latest results. However, in practice, even a single loading of the results page for a solr text search results in 5-6 searches (CPU/disk overhead in site search service), each of which generates an identical WDK cache table, only to be used during the request it was generated by (so clogging the DB up with useless cached results).

Cristina and I had vague memory of our old Oracle text search using a timestamp param for this purpose (cache is good for some period of time, then cache key becomes invalid and must be regenerated). We should go back to this strategy in as many cases as is feasible. Even a 5 minute duration would really help trim down the size/number of cache tables for this type of search.

[aurreco-uga]

current text search has the timestamp

      <paramRef ref="organismParams.text_search_organism" queryRef="organismVQ.forGeneTextSearch"/>
      <paramRef ref="sharedParams.text_expression"/>
      <paramRef ref="sharedParams.document_type" default="gene"/>
      <paramRef ref="sharedParams.text_fields"/>
      <!-- the parameter below caches the results for 30 minutes -->
      <paramRef ref="sharedParams.timestamp" interval="1800" />