remove(feat): fail schema cache lookup with invalid db-schemas config

[steve-chavez]

Closes #4364 by reverting 86c3257

As discussed on #4364, 86c3257 generates several problems:

1. We diverge from database as source of truth because once a schema is dropped, it's not automatically removed from db-schemas and then postgREST fails. Reducing its reliability.
2. We diverge from PostgreSQL search_path lenient behavior:

set search_path to anything, here, even, nonexistent; -- this doesn't fail

3. Schema-based multitenancy becomes more complicated because of 1.

There are no noticeable gains from 86c3257:

• No gains in performance for the schema cache queries.
• No user report about it ever being a problem. In fact the leniency was a feature.

Implementation details

Essentially it removes the $1::regnamespace[] casting for db-schemas that was introduced on 86c3257

[wolfgangwalther]

I don't have the energy to fight about this, so I won't block you, but I also won't approve a change that I think is fundamentally wrong.

1. We diverge from database as source of truth because once a schema is dropped, it's not automatically removed from db-schemas and then postgREST fails

This is just backwards. With this change, the schema cache becomes the source of truth. Schema still in the schema cache? You get a 200 OK. That's not the database as the source of truth.

[steve-chavez]

Schema still in the schema cache? You get a 200 OK. That's not the database as the source of truth.

In this case we'll get an error coming from the database, should be a 404 according to https://docs.postgrest.org/en/v13/references/errors.html#http-status-codes.

[steve-chavez]

That is if you request a table or function. If you request a schema having openapi-mode=follow-privileges, it should be an error.

I haven't tried for openapi-mode=ignore-privileges, but it's possible that a 200 OK happens in that case. If the schema existed before and then was dropped.