mv on_schema_change tests -> "adapter zone"

[jtcohen6]

follow-up to #6330

Description

In the previous conversion PR, @VersusFacit made a reasonable point:

Oh, do we want these imported into any repos? Incremental tests have so many caveats, I'm unsure a direct import is valuable in this case.

All I did was convert the postgres__ tests to ordinary tests to live in tests/functional

As it stands, that these tests have already been living in those other repos, and they were originally written (in #3387) to be cross-adapter compatible. Then, they were copy-pasted everywhere, as part of the Great Adapter Split, in fall 2021 / the lead-up to v1.0.

By moving this test into the "adapter zone" (a.k.a. dbt-tests-adapter), we can inherit it for use in all our adapter repos, and delete a LOT of copy-pasted code.

While here:

• Replace the hardcoded string_type with dbt.type_string() (added in v1.2!)
• Refactor the test setup very slightly so it's easier to extend/repurpose (relevant to dbt-bigquery), without having to run existing test functions multiple times
• Remove the test fixtures, since they were actually unused in the test
• Do a little bit of file renaming / reorg within dbt-tests-adapter (which is v1 distributed software!)

Adapter PRs

• Convert incremental on_schema_change tests dbt-redshift#269
• Convert incremental on_schema_change tests dbt-snowflake#398
• Convert incremental on_schema_change tests dbt-bigquery#469
• Convert incremental on_schema_change tests dbt-spark#593

Checklist

• I have read the contributing guide and understand what's expected of me
• I have signed the CLA
• I have run this code in development and it appears to resolve the stated issue
• This PR includes tests, or tests are not required/relevant for this PR
• I have opened an issue to add/update docs, or docs changes are not required/relevant for this PR
• I have run changie new to create a changelog entry

[github-actions]

Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide.

[ChenyuLInx]

LGTM!

[VersusFacit]

Clearly from my more naive days of test conversions :p

That said, I do recall thinking "should we keep these?" I know they live in the code history and don't necessary need to exist in current code. More a "principles" question: if there are seemingly extraneously models in tests, do we nix them with cautious abandon or seek to add tests to include them? Of course, we merged this without getting much of answer at the time, and I'd love to hear your thoughts if you have any now. 🙇‍♀️

[jtcohen6]

As a general rule: If it's not being actively used in one of our existing tests, we probably don't need it. (There are rare exceptions, where we've added a new fixture/combination with the intent of testing, but completely forgot! I just found an instance where I'd made this mistake a ~while ago: dbt-labs/dbt-bigquery#41)

Longer answer: Intent is a useful input, to the extent we can infer it. In this case, I remember the history as being: our colleague Matt W added this feature (on_schema_change) back in 2021, and he added integration tests for it by copying + adapting some other recent integration tests (for --store-failures). The "tests" component was important for the original tests, but not necessary for these adapted ones.

[VersusFacit]

Appreciate the history lesson! That makes much more sense and I'll run with your heuristic in the future.

[VersusFacit]

Barring the merge conflicts, and my lil' comment, looks good.

Thanks for introducing me to that neat dbt.type_string().