Table Paging and Sorting with filtered client-side data

Summary
=======
An improved filtering UI will enable tables to have standard behavior (sorting, paging, row count) by maintaining the appropriate client-side data. The Eucalyptus “magic search” widget will combine client-side filtering and API filtering.

Motivation
========
Current table UX is prohibitive for >20 items. This BP:
- Adds "Previous" button, paging backward through client-side data.
- Sorts all items (not just current page) for any column, using client-side data.
- Shows current position in entire dataset by getting total count from API (when available).
- Filters multiple columns via table search on client-side data.
- Filters individual columns on server-side data (via APIs) in the same search widget.
- Because of the above, the table needs fewer rows, so you can see header & footer on screen at once.

This design relies only on existing APIs. Elastic Search will solve the same problems with a better UX, but when it is not available it would gracefully degrade to this design.

Description
=========
As background, an AngularJS smart-table can show multiple pages of client-side data. The smart-table can page down and up through the client-side data, and also can sort it by column.

This BP focuses on the interplay between the complete dataset on the server-side and the partial dataset on the client-side. This involves two enhancements to the smart-table:
1. A table filter that filters the client-side data, but also drives API filters as needed.
2. An indicator of size/position in the dataset, and whether the client-side data is complete.

Refer to http://invis.io/U21P372EA for 6 screenshots that walk through a scenario. At the end, a flowchart shows the actual design. The screenshots do not show latest table design or Eucalyptus Magic Search, but refer here for the latter: http://coderslike.us/2015/01/07/magic-search-facets-and-text-in-a-single-widget-for-efficient-search-ux/

The max number of rows to be loaded client-side could be set in the Horizon Settings screen. The default will be determined by performance experimentation, but guesses range from 100 - 1000.

This BP assumes that API filtering can easily get the dataset down to 100-500 rows, which would then be paged/sorted/searched on the client-side. If API filtering can easily get the client-side data down to a single page, then paging/sorting/searching may not be important. The assumption is that it often takes more effort to API-filter from (say) 100 rows down to 20 rows than it would take to page and sort and search.

The design of this BP focuses on the Instances table. However, the initial implementation (e.g. Kilo) would be the Users table, which is being converted to AngularJS first.

UX
===
See http://invis.io/U21P372EA

Testing
======
Test all paths in the flowchart http://invis.io/U21P372EA for each table.
For each column, test with i18n strings:
- filtering by keystroke on the client-side data
- filtering by facet (e.g. API filtering)
Test multiple facets at once.
Test removing facets.

Outside Dependencies
==================
https://blueprints.launchpad.net/nova/+spec/server-count-api is required to get the total number of rows for the Instances table, when it is too many to load client-side. For tables without this API, we will gracefully degrade to something like: “500+”.

Requirements Update Required
========================
Eucalyptus Magic Search must be available.
Angular Smart-Table and other AngularJS libs will already be available.

Doc Impact
=========
Document the new Settings field for max number of rows to load client-side.
Possibly document the behavior of the new filters--but hopefully it will be self-explanatory.