feat: raw output w/ request.accepts

[steve-chavez]

Partly addresses #1582.

BREAKING removes the raw-media-types config
BREAKING no longer Accepts text/xml by default

This already works much better than raw-media-types. We're able to override existing media types and add new ones. For example:

CREATE OR REPLACE FUNCTION my_soap_endpoint() RETURNS text AS $$

BEGIN
  perform set_config('response.headers', '[{"Content-Type": "application/soap+xml"}]', true);

  RETURN xmlelement(
 -- ...
 )::text;
END;
$$ LANGUAGE plpgsql
set request.accepts = 'application/soap+xml, text/xml, application/xml, */*';

With that we can output xml without an explicit Accept header(because it accepts */*), removing the need for Nginx as mentioned here on the docs.

cc @fjf2002

Tasks

• Simple request.accepts for scalar functions
  - [ ] request.accepts for aggregate functions
• Tests
  • A wildcard content-type: / should be accepted(this is valid according to this, it's up to the user to set a correct content type)
• Validation
  • disallow setting request.accepts on a set returning function
  • disallow setting request.accepts on a function that doesn't return text/bytea
    • Maybe this restriction can be lifted, but will leave that for another PR

[steve-chavez]

IMO, this wasn't working properly because the xmlagg function requires a column(unlike json_agg). Will replace this with the aggregate solution mentioned on #1582.

[steve-chavez]

I might be able to make this work without breaking the xml functionality. Will scope this PR to just scalar functions.

[steve-chavez]

Been trying to not break existing xml functionality, but it's turning out to be complicated.

Also, I thought it would be useful to keep the /tbl?select=id Accept: text/plain, but it's a complicated interface; also is really not a scalar response as documented on https://postgrest.org/en/stable/api.html#response-formats-for-scalar-responses since it's not a single value. We would have to enforce a single row is selected, but this is even more complicated for the user and also for us.

Additionally the string_agg issue on a non-text column is always one of the most visited issues #1755 according to https://github.com/PostgREST/postgrest/graphs/traffic (private link).

The only way to get a scalar response is with a scalar returning function, so we should just keep it to that.

Will proceed with breaking the select only one column magic and instead support aggregates.

[steve-chavez]

Closing this one as doing CREATE FUNCTION ... SET request.accepts requires SUPERUSER somehow. I'll continue with the DOMAIN approach discussed on #1582.