Bug 1129298

+++ This bug was initially created as a clone of Bug #1123614 +++

see attachment 924234 [details] that shows at least two problems with the paging mechanism. 
** in the shown setup, I have reduced the default page size to 5, just in order to avoid creating hundreds of items for demonstrating paging-related issues **. 

(1) in my setup, I have 10+ VMs. results for the "VM:" search query return, as expected, the first page (5 items) in the complete VMs list. 
Note that that "Next" paging button is disabled, even though I have more VMs on the next pages. 
[this issue is a regression and will be resolved in the context of bug 1123614]

(2) since displaying the second page of the search results is impossible via the paging buttons, I appended "page 2" to the search query suffix, and indeed - the second page of results appeared, with the "Prev" paging button properly displayed. 
But again, the "Next" paging button was disabled. 
In addition, clicking on the "Prev" button did work as expected and brought me to the first page of results, but the search text remained with the "page 2" text, which is misleading. 

solution
--------
we should theoretically manipulate the search string to contain the correct page number; however, it will be simpler if we will "disable" the option to write the "page" suffix in the search text altogether. 

after discussing with Vojtech: this is what needs to be done (BTW, this will solve some search-sorting behaviors in the GUI as well):

we need a separate search auto-complete behavior for the client: 
currently, the auto-complete behavior is giving the "sortby" and "page " as possible suffixes for the search text. we need to make sure that the SearchBackend won't give these options as possible suffixes. 
** this will require to clone/inherit/... SearchBackend for the client; the "server" auto-complete behavior should remain as is (i.e. should return "sort by" and "page " as possible suffixes for the search string) in order to maintain backward compatibility for the API. **
if the user will "forcibly" write "sortby" / "page" suffixes for the Search text in the GUI, the GUI will treat that just as any other *illegal* search string. 
[this is in line with the client's SearchBackend not returning "sortby" / "page" as part of the auto-complete options].

when the user is paging / sorting using the GUI (i.e. clicks on the "next"/"prev" paging buttons / clicks on a grid column header), we will add the "page" / "sortby" suffixes to the search text *behind the scenes* (i.e. we won't reflect it in the search-text text-box).