add Queryables Management conformance classes

[thomas-maschler]

Introduces two independent conformance classes that let clients modify the queryables advertised by the API at runtime

Related Issue(s):

• allow to write queryables stac-utils/pystac-client#698

Proposed Changes:

• queryables-management-catalog enables PUT on /queryables to replace the catalog-level queryables document.
• queryables-management-collections enables PUT and DELETE on /collections/{collectionId}/queryables to set or remove a per-collection override of the catalog defaults.

The two classes are orthogonal; when Collections is advertised the catalog document acts as the per-collection default whether or not Catalog is also advertised. PUT requires application/schema+json; the server controls $schema, $id, and type and ignores them on input. Concurrent writes resolve last-write-wins. Servers may return 202 Accepted when new queryables cannot be made effective immediately. Auth is out of scope but expected.

PR Checklist:

• This PR has no breaking changes.
• I have added my changes to the CHANGELOG or a CHANGELOG entry is not required.

[m-mohr]

I think the new HTTP methods for transactional queryables are a good addition.

A couple of general comments as also discussed in the STAC community meeting today:

• I think it would make sense to upstream this to OGC API - Features from which this extension is inherits. It could just be an issue in https://github.com/opengeospatial/ogcapi-features/issues for now, asking for their thoughts and whether they would be interested to adopt this, pointing back to this PR.
• It would be good to cover all types of queryables that we have in STAC right now:
  • Global Item Search (named "Catalog" here) - for GET/POST /search
  • Collection Search - for GET /collections
  • Item Search within a specific Collection - for GET /collections/{id}/items
• It might make sense to define the transactional aspects in a separate extension, as this extension is already rather large/complex. It would have the advantage that we could also add similar endpoints for other similar endpoints such as Sortables (see Sort extension)
• "Reverting a Collection to Defaults" is not strictly bound to transactional queryables, I think I'd split this apart to be a separate conformance class (which itself probably won't be upstreamed to OGC API - Features as they don't have /search, but maybe this part could stay in here).

[fmigneault]

Would require a mixture of:

• OGC API - Features - Part 3: Filtering - Queryables
  http://www.opengis.net/spec/ogcapi-features-3/1.0/req/queryables
• OGC API - Features - Part 4: Create, Replace, Update and Delete (ie: Transactions)
  https://docs.ogc.org/DRAFTS/20-002r1.html

The "resources" to which "transactions" apply in this case are STAC Items or Collections.
The "Queryables" are not typically considered "resources", but more like distinct metadata to retrieve these resources. In Part 3, the "Queryables" themselves are not modifiable (just GET).
Therefore, no actual definition currently governs how to advertise conformance of such operations.
A dedicated OGC part (maybe Common?) or a dedicated STAC API Extension seems necessary.

[fmigneault]

FYI: I've opened opengeospatial/ogcapi-common#391 to track this on OGC side.
Feel free to provide more use cases or precisions on it if any additional consideration is missing.