Support various return preference header

[fmigneault]

Description

• Allow specification of return=minimal|representation in Prefer header to control how to return results.
  (equivalent of current response parameter in request body, see Support response: raw execution results #376)
• Provide the Preference-Applied header in response with return if honoured.

Conformance items

• https://github.com/opengeospatial/ogcapi-processes/blob/master/core/recommendations/core/REC_job-results-success-async-many-json-prefer-none.adoc
• https://github.com/opengeospatial/ogcapi-processes/blob/master/core/recommendations/core/REC_job-results-success-async-many-json-prefer-minimal.adoc
• https://github.com/opengeospatial/ogcapi-processes/blob/master/core/recommendations/core/REC_job-results-success-async-many-json-prefer-representation.adoc
• https://github.com/opengeospatial/ogcapi-processes/blob/master/core/recommendations/core/REC_process-execute-success-sync-many-json-prefer-minimal.adoc
• https://github.com/opengeospatial/ogcapi-processes/blob/master/core/recommendations/core/REC_process-execute-success-sync-many-json-prefer-representation.adoc
• https://github.com/opengeospatial/ogcapi-processes/blob/master/core/recommendations/core/REC_process-execute-success-sync-many-json-prefer-none.adoc

References

• return preference: https://datatracker.ietf.org/doc/html/rfc7240#section-4.2
• Get rid of the response parameter from the request body opengeospatial/ogcapi-processes#215
• relates to [Feature] Support Prefer header and improve sync/async execution #247
• relates to Support response: raw execution results #376
• relates to GD-535
• relates to DAC-531

[christophenoel]

I like this proposal ! 👍 (even if I'd prefer to see the output resources links available in the job resource aka 'status' 😆 )

[fmigneault]

@christophenoel
One approach could be to have similar Prefer: return=minimal|representation header for the /jobs/{jobID} status request itself (instead of the execution request).
By default, minimal job status would indicate to omit results inline (as currently defined by the spec), while representation would merge them all together in the status response to avoid the second request to /jobs/{jobID}/results to obtain them.

[christophenoel]

That's a very creative solution that I fully support ! 👍