Implement "text/plain" content type for endpoints supporting it

[uniqueg]

Description

Several endpoints in the TRS specification allow requesting a text/plain response rather than the default application/json response. This is currently not implemented for any of the endpoints.

Proposed solution

To implement this, first a generic function investigating the header should be implemented that accepts a list of defined content types for that particular endpoint as well as either all headers or just the Accept header (if available) associated with the request. The function should then inspect the value of the Accept header and compare it to the list of supported content types. If the requested content type is not in the list of supported content types, a BadRequest should be returned. If the header is absent, the default (application/json) should be returned/set. Otherwise, i.e., if the content type specified in the Accept header is among the list of supported types, it should be returned. This function can be used for all endpoints. Then, depending on which validated content type was requested, the Content-Type header of the response should be set accordingly (e.g., if text/plain was requested, the Content-Type header of the response should be set to text/plain).

Possible caveats

• It is possible that multiple Accept headers are allowed in a request. If so, content has to be negotiated, i.e., a solution has to be implemented to find the most suitable response for an ambiguous request. One obvious solution is to implement the header validation function described above in such a way that the list of supported content types passed to it is ordered and that if multiple Accept headers are provided, the content type is picked that matches the type in the list that is further at the top of that list. For example, if the client requests either Accept: application/json or Accept: text/plain and the supported content types were passed to the function as ['application/json', 'text/plain'], then the function should return 'application/json', as it has a lower list index than text/plain. But before implementing it like that, make sure that multiple Accept` headers are indeed supported by HTTP specs.
• It might be that Connexion - which is used under the hood in TRS-Filer - will complain if trying to return content types other than application/json. There are some related issues on the Connexion issue board that should be carefully read. For example: Content negotiation and response validation assumes incorrect schema for validation spec-first/connexion#860 and Validate Content Type spec-first/connexion#407. There is also this question on Stack Overflow that looks related. If this turn out to be a problem, please post the occurring errors and any other relevant info as a comment to this issue so that we can collaboratively find a solution.