Slow response times in the JIRA FishEye Plugin caused by EyeQL suffering from performance issues

EyeQL currently has many flaws in its implementation leading to poor response times, particularly with the JIRA FishEye plugin

• Searches are either done only against Infdb and sometimes are a join between infdb and lucene
• Sorts are done in memory
• Lucene queries are done against a changeset index, then split into file revisions, only to be aggregated again
• Many queries could be serviced purely by lucene due to stored data
• file revisions are eagerly loaded for every matching file revision, regardless of whether all fields are required of not

Short term solution
Create a separate API to service the JIRA FishEye Plugins needs, optimising the searches as best they can.

Long term solution
Fix EyeQL to:

• Allow searching for changesets, not just file revision
• Do a lucene first query, lazily fetching file revisions or changeset data from infdb
• use lucene for sorting results where possible