Add new option 'maxItemsPerPage'

[vprivat-ads]

This PR adds a new option in config.js:

    maxItemsPerPage: 100,

which allows to define a custom value for the maximum number of items in the search filter:

[m-mohr]

So that's the maximum number a user can enter or the default value that's requested if the user doesn't input a specific number? (edit: seems to be the former)

What's the usecase behind this? Did users enter 10000000 and the server returned an error? Do you want to configure a higher number than the old default? Usually pagination is in place and it shouldn't really matter. Also, Vue will probably not be able to render too high numbers if pagination is not active.

[vprivat-ads]

It's the opposite, I would like to be able to specify a much lower limit (around 100) items for one of our STAC applications that acts as a proxy to another non-stac (OData) system where paginating over 10000 items would be very slow.

We will enforce this limit server-side, but it would be great to make it also appear explicitly in the UI, so that users know how many items they can fetch at most in a single search query.

The other idea that crossed my mind was to advertise this value in the service-desc and make stac-browser use it, instead of defining a new property. Would this be a preferred way to have control on this parameter?

Reference:

The limit parameter follows the same semantics of the OAFeat Item resource limit parameter. The value is a suggestion to the server as to the maximum number of Item objects the client would prefer in the response. The server may return fewer Item objects, but must not return more. The OpenAPI specification defines the default and maximum values for this parameter. The base specifications define these with a default of 10 and a maximum of 10000, but implementers may choose other values to advertise through their service-desc endpoint. If the limit parameter value is greater than the advertised maximum limit, the server must act as if the request were for the maximum and not return an error.

[m-mohr]

Seems reasonable. I'll merge.

STAC historically doesn't use OpenAPI to adverstise server capabilities. It's in the spec as we inherited it from OGC APIs, but no client that I'm aware of makes use of it.