Cherry pick non-breaking fixes for a PATCH version release

[laurenceisla]

Testing cherry picking fixes to release the PATCH version v9.0.1

Applied most commits in this range: ab90bd2 - 6b5370f
excluding the features, breaking changes and other commits related to those. After that last commit there are many features implemented, so I only cherry-picked some small fixes and the relevant commits to the CI files (for this PR to run the tests).

Fixes included:

 - #2165, Fix json/jsonb columns should not have type in OpenAPI spec
 - #2020, Execute deferred constraint triggers when using `Prefer: tx=rollback` - @wolfgangwalther
 - #2077, Fix `is` not working with upper or mixed case values like `NULL, TrUe, FaLsE` - @steve-chavez
 - #2024, Fix schema cache loading when views with XMLTABLE and DEFAULT are present - @wolfgangwalther
 - #1724, Fix wrong CORS header Authentication -> Authorization - @wolfgangwalther
 - #2120, Fix reading database configuration properly when `=` is present in value - @wolfgangwalther
 - #2135, Remove trigger functions from schema cache and OpenAPI output, because they can't be called directly anyway. - @wolfgangwalther
 - #2153, Fix --dump-schema running with a wrong PG version. - @wolfgangwalther
 - #2101, Remove aggregates, procedures and window functions from the schema cache and OpenAPI output. - @wolfgangwalther
 - #2042, Keep working when EMFILE(Too many open files) is reached. - @steve-chavez
 - #2147, Ignore `Content-Type` headers for `GET` requests when calling RPCs. Previously, `GET` without parameters, but with `Content-Type: text/plain` or `Content-Type: application/octet-stream` would fail with `404 Not Found`, even if a function without arguments was available.
 - #2294, Disable parallel GC for better performance on higher core CPUs - @steve-chavez
 - #1076, Fix using CPU while idle - @steve-chavez

[laurenceisla]

Added many of the fixes you mentioned, but these ones may be more complicated so I excluded them:

#2107, Clarify error for failed schema cache load. - @steve-chavez
From Database connection lost. Retrying the connection to Could not query the database for the schema cache. Retrying.

This adds a test for the health check feature here: 51ee07. It can be fixed but may cause problems if a new minor version arises from this branch.

#2152, Remove functions, which are uncallable because of unnamend arguments from schema cache and OpenAPI output. - @wolfgangwalther

It depends on d9f7f6f, which in turn looks like it depends on 52d628. It breaks tests for VARIADIC functions.

#2278, Allow casting to types with underscores and numbers(e.g. select=oid_array::_int4) - @steve-chavez

It uses files created after a refactor.

[steve-chavez]

Including #2239 as it was straightforward.

Edit 1: Nevermind, it depends on d6834e8.

Edit 2: Fixing the test was as simple as removing the "code" attr from the error. So I ended up including it.

[wolfgangwalther]

The out-of-order 9.0.1 patch release causes our version numbers for pre-releases to break the "higher version number means more recent" promise.

We discussed elsewhere (can't find it right now) why we need to tag the pre-release version numbers the way we do now, i.e. a 9.0.0.20220630 pre-release needs to be "bigger" than 9.0.0 - and smaller than 10.0.0. That's why 10.0.0.20220630 as a pre-release before 10.0.0 doesn't work.

But now 9.0.1 came in, which only contains a small subset of changes compared to any 9.0.0.xxx pre-release. So 9.0.1 is not more advanced than 9.0.0.202205xx. But automatic dependency update tools like renovate or dependabot or whatever won't pick up on that.. so they will suggest an "update" from 9.0.0.xxx to 9.0.1 - which breaks things.

This is quite annoying. We shouldn't not make any releases out-of-order and stick with a linear branch history.

A practical approach to ease part of the problem would be to immediately release a new pre-release 9.0.1.20220630. This would then supersede 9.0.1 again. But this will not solve the general problem, that our version history is now not consistent anymore.

[steve-chavez]

A practical approach to ease part of the problem would be to immediately release a new pre-release 9.0.1.20220630. This would then supersede 9.0.1 again.

Done: https://github.com/PostgREST/postgrest/releases/tag/v9.0.1.20220630

But automatic dependency update tools like renovate or dependabot or whatever won't pick up on that.. so they will suggest an "update" from 9.0.0.xxx to 9.0.1 - which breaks things.

Hm, does dependabot work for upgrades on binaries/executables as well? I thought it was only for libraries. Also, does it pull pre-releases? If it sticks to releases only then there shouldn't be a problem.

We discussed elsewhere (can't find it right now) why we need to tag the pre-release version numbers the way we do now, i.e.
This is quite annoying. We shouldn't not make any releases out-of-order and stick with a linear branch history.

I thought it would be preferable to have an out-of-order patch release than two consecutive major releases. I guess we just need to be more careful in merging breaking changes.

I do agree in sticking to linear history. This was an exceptional case and it does require some extra work to make it happen, I don't think we'll do it again.

We discussed elsewhere (can't find it right now)

Maybe we should document the release rules/process in https://github.com/PostgREST/postgrest/blob/main/.github/CONTRIBUTING.md

[wolfgangwalther]

Done: https://github.com/PostgREST/postgrest/releases/tag/v9.0.1.20220630

Thanks.

Hm, does dependabot work for upgrades on binaries/executables as well? I thought it was only for libraries.

I'm using renovate, which is highly configurable and can update a lot of stuff. I'm using an "infrastructure as code" approach so everything that runs on my servers is defined in a git repo. The repo is updated via PRs by renovate and synced with flux to the kubernetes cluster. So whenever a new postgrest docker image is released, I get automated updates / PRs.

Also, does it pull pre-releases? If it sticks to releases only then there shouldn't be a problem.

Well, how would it be able to tell that it's a pre-release? It's just another regular version, but with 4 numbers. And I actually want to use pre-releases. Otherwise I'd be missing a lot of features, due to our low release frequency. I just don't want to have an automated downgrade inbetween...