PB-1677: sort extension - Add sortby query param

[asteiner-swisstopo]

This allows sorting items with a sortby query parameter as defined in the sort extension:

/collections/my-collection/items?sortby=created,-title

The following properties are sortable:

• id
• collection
• datetime
• title
• created
• updated

As we don't support Collection Search, the only affected endpoints are:

• GET /collections/{collectionId}/items
• GET /search with simple filtering
• POST /search with full-featured filtering

Queries in practice look like this:

# GET /collections/{collectionId}/items
curl -X GET \
  "http://127.0.0.1:8000/api/stac/v1/collections/test-collection/items?sortby=datetime"

# GET /search
curl -X GET \
  "http://127.0.0.1:8000/api/stac/v1/search?ids=test-feature-1,test-feature-2&sortby=datetime"

# POST /search
curl -X POST \
  "http://127.0.0.1:8000/api/stac/v1/search" \
  -H "Content-Type: application/json" \
  -H "Authorization: Token my-token" \
  -d '{
    "query": {
      "title": {
        "startsWith": "test-description-A"
      }
    },
    "sortby": [
      {
        "field": "datetime",
        "direction": "asc"
      }
    ]
  }'

Notes:

• Fields are referred to as, e.g., created and not properties.created. I would find properties.created better but the "query" parameter in the /search endpoint also refers to the properties without the properties. prefix. So I favored consistency.
• I extracted tests connected to a STAC extension from test_search_endpoint.py to test_search_endpoint_extensions.py because the file got too long.

Follow-up work:

• Compatibility with STAC Browser
  • A /sortables endpoint listing the sortable properties
  • Advertising the sort extension in the /conformance endpoint
• A /sortables endpoint that takes into account which stac_extensions are declared. For the moment, only core properties are supported.

[boecklic]

Nice 🎉

Adding /sortables will be in a separate PR I guess?

[boecklic]

is this declaration and initialisation correct? below it's defined as an array (which by default is empty), here it's a string..?

[asteiner-swisstopo]

Good catch but it should be fine. According to the DRF docs both works:

• ordering = This should be a string, or list of strings, indicating the field against which the cursor based pagination will be applied. For example: ordering = 'slug'. Defaults to -created. This value may also be overridden by using OrderingFilter on the view.

[boecklic]

the other helper functions are not _* prefixed... why this one?

[asteiner-swisstopo]

Because it is only used within the same module.

According to PEP8:

• _single_leading_underscore: weak “internal use” indicator. E.g. from M import * does not import objects whose names start with an underscore.

The other new functions are used elsewhere, so not just used "internally".

I think that is a common way to mark helper functions, so I keep it as it is.