GET /v2/images with limit doesn't respect sort settings

[Tom Carrio]

If using both "limit" and "sort", the returned subsequent pages are not necessarily in order overall but only within individual pages.

This behavior was exhibited while developing against the gophercloud SDK.

This may be the intended functionality as it is now, but it may be better for pages to consider the sort in regards to all matches when going through pages.

Furthermore, does this behavior mean this is expected of all OpenStack searches? Currently, the limit is set (when None) to the configured API limit. By that, does this mean the following situation would be possible:

With 1000 images returned to match your search, and an API limit of 100 per query, you may have to go through all 10 pages prior to finding the correct match for your search? Since it appears that the exhibited functionality is the sorting is applied to individual pages, it will find 100 matches, sort those, and return that.

I was concerned that may not be the intended functionality, and that if you were searching perhaps the most recent image (on topic with how we found this issue), it should absolutely be the first match in the first page, as well as the last match in the last page would be the oldest image.

Further information with how we came across this and the code involved from skimming through the v2 images code:

- Trace: https://github.com/openstack/glance/blob/master/glance/api/v2/images.py#L181-L191
- Trace: https://github.com/openstack/glance/blob/master/glance/gateway.py#L70-L90
- Trace: https://github.com/openstack/glance/blob/master/glance/api/authorization.py#L110-L112
- Encountered issue: https://github.com/hashicorp/packer/pull/6490/files/9b26a0b6d9a6cdd7e64e3dd3bdd8f313a5628a7e#diff-0dee6a8519558384fb129e344c9f4142R103