History optimization/improvement fix #149

[gazpachoking]

This addresses most of the concerns from #149. It makes a WikiPage.history property, which is an iterator rather than a list. This means thing using the property, like the history view, can use itertools.islice or similar methods to only load up to a certain point. I've also added WikiPage.history_cache, which returns the number of cached items in history, as well as whether the cache is complete. Not super nice, but that info is needed to get good paging functionality in the history view. I've also removed the info property, with reasoning from #148. I didn't delete the usages of it from search indexer or edit page view, which I think should probably also go.

I redid the history view to use datatables, which gets the data via ajax calls. When the history hasn't been fully cached, the data provider will return that there is one more entry available, which means the first time you page through a pages history, the page count grows as you go to each next page. This also eliminates the hard coded 100 revision limit previously imposed on history view. Some points to think about still, and stuff yet to finish:

• [x] Add the gravatar back to the author column
• [x] Add back ability to select revisions and initiate a comparison.
• [x] Re-add button to view at given revision.
• [x] Make date format more consistent with index view?
• [x] When the cache isn't complete the reported total records is one more than we have cached. Perhaps just change that to have a + or something e.g. Showing 31 to 40 of 41+ entries
• Along the same lines, maybe add an ellipsis at the end of the page buttons to indicate there might be more.
• When cache isn't complete, add an 'End' button to the page controls to force loading of all revisions. Editing the paging buttons dynamically seem more complicated than it's worth

EDIT: I think this is good to go now Improvement/change summary:

• History is only calculated for requested items
• Calculated history is now cached
• History cache saved even when updating or renaming a page
• History view is paged, and requests each page via ajax
• History view is not limited to 100 items
• Whole line is selectable rather than checkboxes
• Only 2 lines are selectable at a time to compare, selecting another will deselect the first revision selected.

[gazpachoking]

Hmm, I also just realized you can't compare revisions across pages. Not sure what to do with that.

[gazpachoking]

Okay, I'm much happier with what's going on in here now. I switched from my hacky paged history, to using datatables to get the history using ajax.

[gazpachoking]

Revision comparison is working again. Instead of checkboxes, the rows are selectable, and only the last 2 rows selected remain activated. Your selection is also remembered between pages, so you can compare across page borders. I'm getting really happy with this now.

[gazpachoking]

Okay, I think this is in a good state now. I've fixed most of the issues with the original version, and I think history view is actually improved with this, rather than just being faster.

[gazpachoking]

I noticed that the cache loading would break with renames in the history. While fixing, I noticed it would also be easy to make it so that the history cache can be invalidated without being reset. Newly added revisions will be updated before continuing with cached revisions next time the history is accessed.