Generic max-results and order-by

[MikeTheSnowman]

With fcli SSC's list commands, if you try to limit the number of results being output by using the RESP APIs limit parameter, it won't work for two reasons:

• If any -q options are specified that result in client-side filtering, you may get less results than specified (if some records on the first page don't match) or no results at all (if none of the records on the first page match), even if there are results on next pages that do match the query.
• If we add generic paging support for SSC (similar to FoD and SC DAST), then specifying a limit like this will still result in all records being loaded, they will just be loaded in smaller chunks

Instead, we'd need to add a generic --max-results option, either in OutputMixin (so the option becomes available on all commands) or as a separate Mixin (so we can make this option available only on list commands for example). Alternatively, we could integrate this into the -q option, like -q maxResults=100, not sure whether that's a good idea though.

OutputMixin would then need to keep track of the number of filtered records actually written, and stop making requests for getting a next page once we've written the maximum number of results. Generic functionality in the SSC module would need to update the request to set the appropriate page size; if --max-results is not specified, this functionality adds limit=-1 to the request, or adds limit=<max-results> if --max-results is specified.

As for the --order-by option:

• We'd need to decide whether we want to support ordering on all (list) commands for all possible properties (possibly requiring client-side ordering), or only support this for endpoints that provide server-side ordering, possibly supporting only a limited set of properties
• As this is generic functionality, we should have a generic Mixin (probably in fcli-common) that defines standard ordering options, and then have generic functionality in each product module that retrieves the ordering options from this mixin (if defined on a particular command) and generates the appropriate request parameters. Apart from --order-by, this mixin should also provide an option to specify 'ascending' or descending', rather than requiring the user to understand the server-side orderBy syntax (like using + or - to specify ascending or descending).