Split the Tasks page query apart for performance.
Split the Tasks page query apart for performance.

This is super ugly, but it works.

The problem is that when performing the giant hairball of a SQL query that
filters, orders, and paginates the tasks and selects all the various related
data at once, MySQL won't use the correct indexes.  This results in a filesort
using a temporary table which is horrifyingly slow.

By splitting the query into two, each once turns out to be more efficient:

* The first query filters, orders and paginates.  There are *far* fewer joins
  because it's not trying to select all the related data, so MySQL doesn't get
  confused and will use good indexes.

* The second query uses the IDs from the first to look up the tasks and perform
  all the necessary joins to get the other data.  This is blazingly fast because
  everything is a primary key lookup.

This new setup seems to use good indexes in all the cases I tested.
(cherry picked from commit 3eb0cf1b2a75bceb1b37b3fa8a358e491b397e90)

pculture/unisubs,ofer43211/unisubs,eloquence/unisubs,wevoice/wesub,wevoice/wesub,ReachingOut/unisubs,eloquence/unisubs,eloquence/unisubs,norayr/unisubs,norayr/unisubs,pculture/unisubs,ofer43211/unisubs,wevoice/wesub,pculture/unisubs,pculture/unisubs,ujdhesa/unisubs,ofer43211/unisubs,ReachingOut/unisubs,ReachingOut/unisubs,eloquence/unisubs,ujdhesa/unisubs,norayr/unisubs,ReachingOut/unisubs,ofer43211/unisubs,norayr/unisubs,wevoice/wesub,ujdhesa/unisubs,ujdhesa/unisubs