-importance sort order uses bug task id for stability

[Robert Collins]

For this url: https://bugs.launchpad.net/launchpad-project/+bugs?field.importance=High&field.status=Confirmed&field.status=Fix+Committed&field.status=In+Progress&field.status=Incomplete&field.status=New&field.status=Triaged&search=Search&direction=backwards&start=825

I currently see the last 5 bugs as:
High
Triaged
#919369 cannot retarget bugtask and update status at the same time
Launchpad itself Tags: 404 bugs javascript 0 out of 4 heat flames

High
Triaged
#757007 total_size element returned in all batch retrievals
lazr.restfulclient Tags: None 0 out of 4 heat flames

High
Triaged
#918307 Declares that it requires the test dependencies, but doesn't depend on them, breaking other python code
lazr.restfulclient Tags: None 0 out of 4 heat flames

High
In Progress
#920566 private_bugs is not exposed over the API
Launchpad itself Tags: bugs disclosure privacy projects 0 out of 4 heat flames

Note that these are all high and the sort is by -importance. Historically we used to use the bug id for stability, (so would have had -importance, +bug.id, +task.id) but now are not including the bug id. This is a little surprising for users (heck, it surprised me and I suspect I made that change for performance).

We might want to examine the ramifications of putting it back in (or denormalising onto whatever search schema we have (e.g. tasks).

[William Grant (wgrant)]

This is cheap to do now. We just need to add the new indices to BugTaskFlat, change the tiebreaker in lp.bugs.model.bugtasksearch, and drop the old indices.